---
title: 'CSTEapp: Multi-Domain Research Applications'
url: https://www.emergentmind.com/topics/csteapp
type: topic
---

# CSTEapp: Multi-Domain Research Applications

CSTEapp is a reused software name in arXiv-indexed research rather than a single canonical system. In the available literature, it denotes at least three unrelated applications: an ACS-based control and engineering application for the SST-1M small-size telescope within the Cherenkov Telescope Array, an interactive R Shiny application for covariate-specific treatment effect curves and individualized treatment rules in precision medicine, and a mobile application for Mantoux skin test analysis that is also referred to as TBCheck [1709.04244] [1508.07472] [2508.15265] [2506.17954]. This terminological overlap is itself a substantive feature of the topic, because technical discussion of “CSTEapp” is domain-dependent.

## 1. Disambiguation across research domains

The term “CSTEapp” is used for distinct software artifacts with different methodological bases, implementation stacks, and operational goals.

| Usage of the name | Research domain | Core stack or framework |
|---|---|---|
| SST-1M control and engineering application | CTA telescope control | ACS, OPC UA, Java, Python, C/C++ |
| Covariate-specific treatment effect application | Precision medicine and causal inference | R Shiny, CSTE, fda, ggplot2, plotly |
| Mantoux skin test evaluation application | Mobile medical image analysis | Android, ARCore, CameraX, DeepLabv3, PyTorch Mobile |

A common misconception is to treat CSTEapp as a single software framework. The literature instead uses the same name for systems that share no common architecture beyond being research applications. In one lineage, CSTEapp is telescope-control middleware centered on ACS and OPC UA for subsystem orchestration within CTA [1709.04244]. In another, it is the first application for estimating the ITRs based on CSTE curves and SCBs, implemented as a web-based R Shiny system for binary and survival outcomes [2508.15265]. In a third, it is an Android-based image-analysis application for standardized Mantoux TST reading using ARCore, scaling stickers, and on-device segmentation [2506.17954].

## 2. CSTEapp in precision medicine: causal estimand, models, and decision rules

In the precision-medicine literature, CSTEapp is an interactive, web-based application built on the R Shiny framework that implements the covariate-specific treatment effect curve for visualizing individualized treatment rule. Its stated purpose is to make advanced CSTE methodology, including simultaneous confidence bands, accessible through simple “point-and-click” operations without requiring programming, while supporting binary outcomes and time-to-event outcomes in both intervention studies and observational studies [2508.15265].

For binary outcomes, the framework adopts the standard potential-outcomes notation with observed outcome $Y$, treatment indicator $Z \in \{0,1\}$, covariates $X$, and potential outcomes $Y^1, Y^0$. Consistency is expressed as
$$
Y = Z\,Y^1 + (1-Z)\,Y^0.
$$
The covariate-specific treatment effect is defined as the difference in log-odds under the two potential outcomes:
$$
\mathrm{CSTE}(\boldsymbol x) = \logit\{E(Y^1 \mid \boldsymbol X = \boldsymbol x)\} - \logit\{E(Y^0 \mid \boldsymbol X = \boldsymbol x)\},
$$
with $\logit(u) = \log(u) - \log(1-u)$. Under unconfoundedness,
$$
\mathrm{CSTE}(\boldsymbol x) = \logit\{E(Y \mid \boldsymbol X = \boldsymbol x, Z=1)\} - \logit\{E(Y \mid \boldsymbol X = \boldsymbol x, Z=0)\}.
$$
CSTEapp fits the single-index logistic model
$$
\logit\{\mu(\boldsymbol X,Z)\} = g_1(\boldsymbol X^\top \boldsymbol\beta_1)\,Z + g_2(\boldsymbol X^\top \boldsymbol\beta_2),
$$
where $\mu(\boldsymbol X,Z)=E(Y\mid \boldsymbol X,Z)$, and the CSTE curve is
$$
\mathrm{CSTE}(\boldsymbol x) = g_1(\boldsymbol x^\top \boldsymbol\beta_1).
$$

For time-to-event outcomes, the application uses a hazard-based definition. With two treatments, the conditional hazard functions are
$$
\lambda^z(t\mid x) = \lim_{\Delta t\to 0} \dfrac{P(t \le T^z < t+\Delta t \mid T^z \ge t, X=x)}{\Delta t},
$$
and the CSTE at time $t$ is the log-hazard ratio
$$
\mathrm{CSTE}(x,t) = \log\{\lambda^1(t\mid x)\} - \log\{\lambda^0(t\mid x)\}.
$$
CSTEapp focuses on models where $\mathrm{CSTE}_k(x,t)\equiv \mathrm{CSTE}_k(x)$, including the varying-coefficient proportional hazards model
$$
\lambda(t\mid X, \boldsymbol Z) = \lambda_0(t) \exp\{\boldsymbol\beta(X)^\top \boldsymbol Z + g(X)\},
$$
for which
$$
\mathrm{CSTE}_k(x) = \beta_k(x).
$$
Multiple-treatment comparisons are handled by linear contrasts $\boldsymbol l^\top \boldsymbol\beta(x)$.

The causal interpretation of these curves is conditional on explicit identification assumptions. For binary outcomes these are consistency, exchangeability $\{Y^0, Y^1\} \perp Z \mid \boldsymbol X$, and positivity $0 < P(Z=1\mid \boldsymbol X=\boldsymbol x) < 1$. For time-to-event outcomes, the stated assumptions are exchangeability for each treatment arm, independent censoring $C \perp T \mid X$, and positivity in multi-arm settings [2508.15265].

The individualized treatment rule is derived from the sign of the estimated CSTE curve together with its simultaneous confidence band. If the SCB lies entirely below zero at a patient-specific index or biomarker value, the application recommends the treatment associated with lower lnOR or lower hazard; if the SCB lies entirely above zero, it recommends against the corresponding treatment; and if the SCB covers zero, it reports no significant difference at level $1-\alpha$. The app emphasizes SCB-based regions rather than a sign-only rule, thereby quantifying decision uncertainty [2508.15265].

## 3. Estimation, interface, and empirical demonstrations in the R Shiny application

For binary outcomes, coefficient estimation depends on dimensionality. When $p=1$, the app maximizes the log-likelihood to estimate $\beta_1,\beta_2$; when $p>1$, it maximizes a penalized log-likelihood implemented in C, with a tuning parameter controlling sparsity and model choice by least BIC. The unknown functions $g_1(\cdot)$ and $g_2(\cdot)$ are approximated by B-spline basis functions using the R package `fda` and `bsplineS`, and the spline-backfitted kernel technique is applied to re-estimate $g_1(\cdot)$ for SCB construction. For survival outcomes, the app uses local partial likelihood with first-order Taylor expansions around $x_0$ to estimate the local parameters in the varying-coefficient proportional hazards model; SCBs for contrasts are obtained by bootstrap resampling following Zhou (2012) and Ma (2017) [2508.15265].

The application is available at `https://alain003.phs.osaka-u.ac.jp/mephas_web/11cste/` and is described as running on Ubuntu 22.04.4 LTS with R 4.3.3 and R Shiny, using packages including CSTE, fda, ggplot2, and plotly. Its interface is organized into the tabs “Wiki,” “Binary outcomes,” and “Survival outcomes,” with a “Close and more” button for stopping and restarting. Data are uploaded as CSV in tidy format, with columns as variables and rows as observations. The workflow is explicitly divided into three stages: “Step 1” for estimation of $\widehat{\boldsymbol\beta}_1$ or survival local parameters, “Step 2” for estimation of the CSTE curve and SCB, and “Step 3” for uploading new subjects for prediction [2508.15265].

Outputs include static and dynamic plots of CSTE plus SCB, with the estimated CSTE shown as a red curve and the SCB as blue curves. In prediction mode, vertical dashed lines mark patient-specific index or biomarker values, and the interface provides interactive display of IDs and coordinates. Numerical summaries include cutoff points and positive or negative regions defined by SCB intersections with zero [2508.15265].

The paper reports four worked examples. In AIDS Clinical Trials Group Study 175, with 2,139 subjects and an analysis on 2,100 with 39 for prediction, the estimated CSTE curve had negative regions at $[-1.88, -1.02]$ and $[-0.02, 1.07]$; patients whose predicted indices fell in those regions were recommended alternative treatment at 95% confidence. In a simulated binary-outcome dataset with 20 covariates and 2,000 observations, penalized estimation over the tuning grid $0.001$–$0.01$ yielded an optimal model at $0.008$ by least BIC, with negative regions $(−\infty, −0.49]$ and $[1.32, \infty)$. In a survival example on leukemia transplantation types with 80 observations, the dynamic CSTE suggested that younger than 33 might benefit from haploidentical transplantation and older patients might benefit from HLA-matched sibling donor transplantation, but the SCB crossed zero and therefore indicated no statistically significant differences across age. In a multi-arm simulated survival setting with treatments A, B, and C, the contrast $\boldsymbol l^\top=(1,0)$ produced a cutoff near $0.94$ for treatment A versus C, while $\boldsymbol l^\top=(0,1)$ produced cutoffs near $0.20$ and $0.80$ for treatment B versus C [2508.15265].

The paper is explicit about what is not yet provided. Coverage of SCBs and specific value or regret metrics are not reported; survival SCBs rely on bootstrap resampling and may incur computational delay of a few seconds; and survival outcomes are presently implemented with a single covariate, with extension to multiple covariates identified as future work. This suggests that the application is primarily oriented toward graphical uncertainty quantification and decision support rather than benchmark-heavy evaluation [2508.15265].

## 4. CSTEapp in CTA instrumentation: control and engineering application for SST-1M

In CTA instrumentation, CSTEapp denotes the control and engineering application for the SST-1M small-size telescope prototype. SST-1M is a 4-m Davies–Cotton atmospheric Cherenkov telescope proposed as one of the SST types for CTA’s southern site, optimized for gamma-ray sensitivity above a few TeV and covering roughly $3$–$300$ TeV. The telescope has a single-mirror Davies–Cotton design, a 4-m reflector, focal ratio $1.4$, focal length $5.6$ m, and is designed to address CTA SST performance requirements including a point-spread function of $16$ mm, pixel angular size $\le 0.25^\circ$ at $4^\circ$ off-axis, at least $80\%$ of camera FoV covered with optical time spread $< 1.5$ ns $(\sigma)$, and FoV $\ge 8^\circ$ [1709.04244].

The role of CSTEapp in this context is orchestration. It controls all telescope subsystems, provides autonomous and CTA-driven operation modes, ensures safety, manages pointing and tracking, configures the camera, and supplies an engineering web-GUI for operations and maintenance. The software adopts CTA’s standard control architecture built on ALMA Common Software, with each telescope subsystem represented as an ACS component exposing properties, commands, and events. ACS contributes a CORBA-based component and container framework, synchronous and asynchronous interaction patterns, and event notifications. The main subsystem components are Active Mirror Control, drive system PLC, Safety PLC, PDP component(s), DigiCam, lid CCD, sky CCD, telescope master component in Python, and a data acquisition component in C/C++ [1709.04244].

The hardware interfacing layer is centered on OPC UA where available. Safety PLC and drive PLC provide native industrial-grade OPC UA servers. Other subsystems use service wrappers or direct ACS integration: DigiCam uses a custom protocol wrapped into OPC UA nodes; the PDP uses CAN bus via DigiCam firmware acting as a UDP-to-CAN proxy, with a PDP OPC UA bridge implemented in Python; Allied Vision camera APIs for the lid and sky CCDs are exposed through OPC UA bridges provided by the MST team; and the AMC subsystem, which lacks native OPC UA, communicates through telnet with AT-like commands to a ZigBee wireless controller [1709.04244]. The earlier SST-1M control-system design paper presents the same general abstraction at telescope level, organized around five subsystems—AMC, CCD, PLC, Camera Server, and Camera Slow Control—and emphasizes software uniformity with CTA Medium-Size Telescopes through shared CCD and drive-PLC components [1508.07472].

A key architectural property is the device/property model. Subsystem data points are exposed via ACS properties with associated metadata such as units, resolution, and description, while asynchronous callbacks propagate changes and alerts so that the master can react immediately to interlocks, faults, and environment thresholds. Engineering clients, including the master and web-GUI backend, use the Python modules `ACSWorker` and `ACSDatapoint` to subscribe to updates and issue commands [1709.04244].

## 5. Telescope operations, subsystem control, and data acquisition pathway

The subsystem descriptions are unusually detailed. In AMC, each of the 18 mirrors has two actuators, with a ZigBee wireless controller as master; tasks include mirror alignment procedures, actuator positioning, and status diagnostics. In the drive system, a drive PLC with motor controllers performs slewing and tracking, exposing a native OPC UA server and accepting position and velocity commands, lock and unlock, and status reads. The validated mechanical envelope is azimuth $-270^\circ$ to $+270^\circ$ and elevation $0^\circ$ to $91^\circ$. The Safety PLC continuously monitors environmental sensors and enforces safety procedures and interlocks, including subsystem power states, park and lock commands, and transitions to safe or fault modes upon threshold violations or errors. The photo-detection plane consists of 1296 G-APD (SiPM) pixels fed by hollow light-guide cones; its ACS-facing tasks include common and per-pixel HV control, bias settings, temperature and voltage telemetry, and sector health. DigiCam is a fully digital readout and trigger system that enables dead-time-free acquisition and exposes telemetry including trigger rates, buffer status, firmware version, and configuration parameters [1709.04244].

The telescope master organizes operation through control modes—Local, GUI, and Remote—and through a state machine with the key states Off, Safe, Standby, Ready, Observing, Calibration, Maintenance, and Fault. The state progression is operationally explicit: in Safe, subsystems are off and the telescope is parked automatically when entering from Standby; in Ready, the master connects to DigiCam slow control, PDP, and both CCDs and starts imaging; in Observing, the drive is initialized, the telescope is unlocked, slewing and tracking are enabled, PDP HV is turned on, DigiCam starts triggering and readout, and the camera lid is open. On Fault, the master requests telescope logs and publishes them for ACTL consumption [1709.04244].

The camera and DAQ pathway is elaborated in the earlier design study. DigiCam digitizes PDP signals via FADC with 4 ns sampling and applies local camera-trigger logic. If triggered, DigiCam sends bulk data packets over 10 Gbit/s to the Camera Server, which performs local event building, packet sequencing verification, completeness checks, and filtering of duplicated, late, out-of-sync, and erroneous packets. Events are kept for up to 10 s in a circular buffer. Camera-DAQ forwarding uses 0MQ for networking and Protocol Buffers for data encapsulation, as recommended by ACTL, while the Camera Server communicates with CDTS and SWAT over 1 Gbit/s links. A local camera-triggered event is about 64 KB, and the required link throughput is expressed as $B = R \times S$ with event rate $R$ and payload $S \approx 64 \times 1024$ bytes [1508.07472].

Timestamping is provided either by a native White Rabbit interface, giving sub-nanosecond precision, or via CDTS and the UCTS board, with timestamp forwarding at nanosecond precision and an absolute clock with $1\,\mu$s precision. The Camera Server validates timestamps and consults SWAT to determine whether a local trigger belongs to an array trigger, a calibration event, or a special event; only positive cases are forwarded to DAQ [1508.07472].

Operational validation is reported in stages. Early operations without the camera included successful telescope slewing and tracking, CCD-based pointing with simultaneous imaging of stars, Safety PLC state changes, continuous telemetry across subsystems, automatic error responses, and mirror alignment by the bokeh method. Week-long continuous tests connected the Safety PLC in Krakow via RS-485 bridged over the Internet to a housekeeping board in Geneva that read humidity, air pressure, and temperature at multiple points inside the camera; those telemetry channels fed the Safety PLC logic against predefined thresholds to protect the camera. The camera was later reported as fully assembled, with PDP and DigiCam integration complete and data acquisition exercised using an artificial light source in the laboratory [1709.04244].

The telescope-control literature also states a limitation: explicit control or pointing equations are not published, although representative qualitative forms are given for astronomical coordinate mappings and PID-like servo control. A plausible implication is that the control-software papers were intended primarily as systems-integration documents rather than final performance characterizations [1709.04244].

## 6. CSTEapp as a mobile Mantoux skin test analysis system

A third use of the name appears in mobile health informatics, where CSTEapp describes a mobile application for Mantoux Tuberculin Skin Test reading for latent tuberculosis infection; the paper also refers to it as TBCheck. The application is intended to standardize and automate TST interpretation, addressing manual ball-point pen and ruler measurements that are subjective, operator-dependent, and sensitive to experience, skin tone, lighting, and technique. It also addresses missed follow-up readings 48–72 hours after test placement and the lack of trained personnel in resource-limited settings [2506.17954].

The application runs on a compatible Android smartphone and uses ARCore and CameraX for acquisition guidance. ARCore provides motion tracking and camera pose estimation via Concurrent Odometry and Mapping with feature points and IMU fusion, plane detection, and a Depth API with a `getMillimetersDepth` function for millimeter-scale depth in the working region. The image-capture interface presents an Orientation Panel targeting near $0^\circ$ pitch and roll and a Depth Value Panel targeting $175$–$400$ mm, with experiments identifying an optimal range around $219$–$220$ mm for a 10 mm mock induration. When quality checks pass, the app auto-captures and crops a central $450 \times 450$ px region [2506.17954].

Measurement depends on a fiducial scaling sticker of known physical size placed near the injection site. The stated novelty relative to earlier 3D-reconstruction apps is the use of this scaling sticker as an in-frame reference for pixel-to-millimeter conversion. Segmentation is performed on-device using DeepLabv3 with a ResNet-50 backbone optimized for mobile through PyTorch Mobile. The training data comprised 2,298 annotated skin lesion images from PAD-UFES-20. The paper states that SAM and YOLO instance segmentation were evaluated, but DeepLabv3 yielded the best real-time performance on device. After segmentation, the app extracts the induration boundary by scanning boundary pixels and computes the longest straight line across the detected boundary through Euclidean distances:
$$
d = \sqrt{(x_2-x_1)^2 + (y_2-y_1)^2}.
$$
If the scaling sticker is used, the conversion factor is
$$
\alpha = S_{\mathrm{mm}} / S_{\mathrm{px}},
$$
and the diameter in millimeters is
$$
d_{\mathrm{mm}} = \alpha \, d_{\mathrm{px}}.
$$
The paper also reports empirical scalar factors of $0.1197$, $0.1523$, and $0.1499$ for diameter buckets $<50$ px, $50$–$80$ px, and $80$–$200$ px respectively, with Experiment 3 giving optimal scalar factors $0.1197$ for 5 mm, $0.1523$ for 10 mm, and $0.1399$ for 15 mm clay indurations [2506.17954].

Clinical interpretation is assisted by a questionnaire on patient-specific risk factors. The application uses the measured induration diameter to support thresholds of $\ge 5$ mm for HIV-infected persons, recent contacts of TB cases, and persons with immunosuppression; $\ge 10$ mm for recent immigrants from high-prevalence countries, injection drug users, residents or employees of high-risk settings, children under 5, and other clinical risk factors; and $\ge 15$ mm for persons with no known risk factors. The paper presents this as decision support rather than replacement of clinical judgment [2506.17954].

Evaluation is partial rather than definitive. Usability testing with $n=10$ found that $60\%$ felt confident using the app, $50\%$ found it easy to use, $74\%$ appreciated the user experience, and $80\%$ needed assistance. The paper reports that DeepLabv3 showed improved training accuracy and reduced validation loss relative to SAM and YOLO, but exact segmentation metrics such as precision, recall, F1, or mIoU are not provided. Direct comparisons against clinician ball-point pen measurements using ICC, Bland–Altman analysis, MAE or RMSE, and sensitivity or specificity are likewise not reported. The authors identify future work in refining DeepLabv3, improving ARCore-aided measurement under varied lighting, collecting real clinical TST data across diverse skin tones, and expanding data management and interoperability features [2506.17954].

Across these three literatures, “CSTEapp” therefore designates a statistical decision-support environment, an observatory control system, and a mobile diagnostic imaging application. The shared label masks substantive heterogeneity in scientific purpose: causal effect visualization with uncertainty-aware individualized treatment rules in one case, distributed subsystem orchestration and DAQ integration in another, and AR-guided image-based biometric measurement in the third [2508.15265] [1709.04244] [2506.17954].

Source: https://www.emergentmind.com/topics/csteapp