C-Koordinator Platform Architecture

• C-Koordinator Platform is a family of coordination architectures that decouple control logic from computational components across diverse domains.
• It standardizes criteria like interface extensibility, customizable optimization goals, and black-box componentization to ensure scalable and reusable designs.
• Applications span from component-based robotics and microservice interference management to SDN-controlled QKD networks and demand-driven C-ITS orchestration.

Searching arXiv for the cited papers and closely related records to ground the article. arxiv_search(query="(Poss, 2013) OR (Klotzbücher et al., 2013) OR (Song et al., 24 Jul 2025) OR (Mendez et al., 14 Mar 2026) OR (Zanger et al., 23 Sep 2025)", max_results=10) C-Koordinator Platform designates, across the cited literature, a set of coordination-oriented platform architectures rather than a single monolithic software artifact. In these works, the term is associated with objective coordination criteria in programming technologies, the Coordinator–Configurator split for component-based robotics, CPI-driven interference management for large-scale co-located microservice clusters, SDN-based control of switched QKD networks, and demand-driven orchestration for cooperative intelligent transport systems (C-ITS) (Poss, 2013, Klotzbücher et al., 2013, Song et al., 24 Jul 2025, Mendez et al., 14 Mar 2026, Zanger et al., 23 Sep 2025). The common substrate is explicit coordination of independently provisioned components, services, or network elements under runtime state, policy, or optimization constraints.

1. Coordination as an objective platform property

A foundational formulation appears in the argument that coordination should not be defined by opposition to computation. The central critique is that “the common approach that contrasts coordination with computation is intellectually unsound: depending on the selected understanding of the word ‘computation’, it either captures too many or too few programming languages,” and that such phrasings “cannot be used to support specialized scientific attention towards ‘coordination’ as a research activity” (Poss, 2013). In place of negative definitions, the work proposes objective criteria for evaluating how well programming technologies offer coordination services.

Within that formulation, coordination is restricted to languages and infrastructures that enable component-based design. Components are “defined by their interface, which specifies how they can be used in applications, and one or more implementations which define their actual behavior.” Two principles are central: “interface-based integration,” under which a designer relies only on interface guarantees and can substitute implementations without changing the rest of the application, and “reusability,” under which a component can be reused in multiple applications without modification (Poss, 2013).

Seven criteria are catalogued: separable provisioning, interface extensibility, separable scheduling, adaptable optimization, customizable optimization goals, black-box componentization, and exploitable Turing-incompleteness. The decisive result is that only three are strongly characterizing: interface extensibility, customizable optimization goals, and black-box componentization. By contrast, separable provisioning, separable scheduling, and adaptable optimization are treated as widespread prerequisites, while exploitable Turing-incompleteness is rare and not robust (Poss, 2013).

Trait	Definition	Example
Interface extensibility	The infrastructure enables an application designer to redefine and extend component interfaces independently from component providers, and extended interfaces can influence execution	Annotating a component post hoc as functionally pure so execution parallelism can increase
Customizable optimization goals	The application designer can specify different optimization goals at run-time, or no earlier than when specification work has completed, and the technology chooses different execution strategies based on them	Selecting between “run fast” and “use less memory” during execution
Black-box componentization	The application designer can specify an application using components only known to the technology by name and interface, and the technology provides a run-time interfacing mechanism previously agreed upon with component providers	Linking component codes compiled from different programming languages without requiring link-time cross-optimization

The same evaluation identifies AstraKahn, Intel CnC, OpenCL, POSIX, and VMWare ESX as strongly coordinating at different preferred granularities: boxes, steps, kernels, threads/processes, and virtual machines, respectively (Poss, 2013). This establishes a domain-independent vocabulary for judging later C-Koordinator-style systems.

2. Coordinator–Configurator architecture in component-based robotics

In robotic systems, C-Koordinator is concretized as the Coordinator–Configurator pattern. Coordination is defined there as the system-level concern of “commanding, configuring and monitoring functional computations such that the system as a whole behaves as desired,” typically by means of Petri nets, finite state machines, Statecharts, or UML FSMs (Klotzbücher et al., 2013). The critique is directed at “rich” coordinators that directly invoke platform-specific operations.

Three deficiencies motivate the split. First, platform coupling contaminates the coordination model with middleware-specific details and reduces reuse across robots and frameworks. Second, temporal non-determinism arises when blocking platform calls execute inside the coordinator, undermining responsiveness. Third, robustness degrades because blocking or crashing calls can render the coordinator itself inoperative (Klotzbücher et al., 2013).

The proposed decomposition separates a Pure Coordinator from a Configurator. The Pure Coordinator retains control over commanding and reacting: it decides which configuration should be applied, reacts to monitor events and Configurator status reports, and supervises constraints through dedicated monitor components. The Configurator executes platform-specific actions when instructed, holds named configurations, applies them declaratively, and emits status events indicating success or failure. Action execution is therefore deferred: instead of invoking operations directly, the coordinator sends an event identifying a configuration, and the Configurator performs the work asynchronously (Klotzbücher et al., 2013).

The Configurator DSL is organized around named Configuration entries comprising pre_conf_state, post_conf_state, and changes. The Configurator guarantees ordering only for the runtime states listed in pre_conf_state and post_conf_state; the individual changes such as property_set, port_write, and operation_call are not otherwise ordered. If precise ordering is required, the design requires splitting work into multiple configurations and sequencing them in the coordinator. The presented DSL does not provide explicit transactional rollback, and inverse configurations must be specified manually (Klotzbücher et al., 2013).

The case study is a safe haptic coupling application for two KUKA youBot mobile manipulators. The system includes Cart_Impedance, Dynamics, communication components with QoS monitoring, and an rFSM statechart coordinator. States include unsync, sync, harmonizing, copying, eight_DOF_mode, and five_DOF_mode. Specific actions delegated to the Configurator include port_write("Cart_Impedance.ext_ref_mode", true/false) for enabling or disabling coupling and property_set("Dynamics.force_gain", {0.1,0.1,0.1}) or {0,0,0} for eight-DOF and five-DOF operation (Klotzbücher et al., 2013). The implementation environment is Orocos RTT, with rFSM for coordination and a Lua-based internal DSL implemented as an RTT component.

The resulting architecture is explicitly agnostic to coordination semantics: the split works with Petri nets, FSMs, Statecharts, UML FSM, and rFSM without altering their formal semantics. Its stated benefits are improved reusability, improved determinism through deferral of blocking calls, and improved robustness through isolation and status-based recovery (Klotzbücher et al., 2013).

3. Interference-aware management of co-located microservice clusters

A later and substantially different C-Koordinator platform addresses large-scale, co-located microservice clusters. In that setting, the principal problem is interference among microservices competing for CPU cores and caches, memory bandwidth, I/O, and network resources. The production context described includes Alibaba clusters in which over 60% of nodes host more than 15 applications, more than 30% of online services experience resource contention at peak load, and controlled experiments with Nginx at 100 QPS show P99 latency spikes up to $22.9\times$ under injected CPU and memory interference (Song et al., 24 Jul 2025).

The platform adopts CPU cycles per instruction as the main interference signal,

$$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$

because it is low-level, hardware-derived, uniform across applications, and less influenced by request patterns and upstream or downstream dependencies than tail latency. CPI is used both as the supervisory outcome for prediction and as the operational threshold for mitigation (Song et al., 24 Jul 2025).

Prediction is performed by an XGBoost-based regression model with multi-dimensional inputs drawn from pod-, node-, and system-level metrics. The model is expressed as

$\widehat{\mathrm{CPI}} = f(\mathbf{x}),$

with online inference over rolling windows. The production-hardened predictor uses a carefully selected nine-metric subset; sampling interval is 5 seconds, and the rolling window is 60 samples, or 5 minutes (Song et al., 24 Jul 2025). Detector logic computes CPI deviation and a load-aware dynamic threshold, then classifies severity through

$$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$

The architecture extends Kubernetes and Koordinator with an add-on interference module while reusing the Koordinator Scheduler and Koordlet. Koordlet performs CPU, memory, network, and disk profiling; the scheduler provides QoS-aware scheduling, differentiated SLO management, load balancing, and resource overcommitment. The add-on module contains a metric aggregator, CPI predictor, interference detector, scheduler or coordinator and placement engine, mitigation executor, and feedback controller (Song et al., 24 Jul 2025). Operational flow is: metric collection, node-level selection, CPI prediction and deviation estimation, interference decision, mitigation action, and feedback-driven stabilization.

Mitigation is two-tiered. For mild interference, C-Koordinator applies CPU suppress by cgroup CPU share or quota reduction for low-priority pods. For severe interference, it performs pod eviction via Kubernetes APIs for pods exceeding a configurable CPU fraction $\mu$. The decision threshold is explicitly $\mathrm{CSI} < 5/3$ for CPU suppress and $\mathrm{CSI} \ge 5/3$ for eviction (Song et al., 24 Jul 2025).

Evaluation is reported at both production and experimental scales. The system is tested on a $\sim 7{,}000$-node Kubernetes cluster and in reproducible 10-node Alibaba g9i experiments. Across diverse applications, interference prediction accuracy consistently exceeds 90.3%. Compared with baseline Koordinator, latency is reduced and stabilized across P50, P90, and P99 response time, with improvements ranging from 16.7% to 36.1% under various system loads; for Nginx, as RPS scales to 200, P50–P99 reductions are 10.7% to 36.1% (Song et al., 24 Jul 2025). Incremental overhead is reported as approximately 1%–3% CPU under high-pressure migrations, only approximately 0.03% of applications are regularly flagged and trained, and average training time per application is less than 30 seconds.

The paper also delimitates the applicability of the design: CPI is less predictive for I/O-bound or network-intensive services, GPU or accelerator interference is not captured, and current control is thresholded and local rather than globally optimized (Song et al., 24 Jul 2025).

4. SDN control of switched QKD networks

In switched QKD networks, C-Koordinator is the Switching Coordinator, an SDN application that centrally orchestrates switching capabilities, telemetry, and policy-driven reconfiguration. The operational problem is that multiple QKD transmitters, receivers, and shared switching resources cannot serve all module pairs simultaneously; the active physical links and their durations must adapt to changing demand, buffer states, and failures (Mendez et al., 14 Mar 2026).

The architecture is organized in three layers. The key-service layer exposes end-to-end keys to consumers through a local keystore interface. The key-forwarding layer maintains link buffers and performs trusted-node forwarding, deriving per-link consumption rates $r_{\mathrm{cons},l}(t)$. The key-generation layer activates physical QKD links to fill those buffers. Over these layers sits SDN control, comprising an SDN controller, telemetry and monitoring agents, data stores, switching elements, and the Switching Coordinator itself (Mendez et al., 14 Mar 2026).

Telemetry includes switching capabilities, supported wavelengths and protocols, link buffer capacities and fill levels $B_l(t)$, generation rates $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$0, consumption rates $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$1, and health events. The global network state is represented with nodes, abstract links, physical links, admissible configurations, and end-to-end paths. Configuration-dependent generation is captured by a matrix $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$2, while schedules are encoded by a nonnegative duration vector $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$3 whose entries sum to at most 1 (Mendez et al., 14 Mar 2026).

Control follows a monitor–analyze–plan–execute cycle. The controller updates network structure and state on timers or events; the Coordinator computes supported consumption, fairness, and risk metrics; it then solves an optimization or applies an event-driven heuristic; and execution reprograms switching elements and QKD modules, scheduling subsequent configuration changes or recalculation interrupts (Mendez et al., 14 Mar 2026).

Two principal strategies are described. MMAK, “maximize minimal average key in the link buffers,” solves a linear program maximizing the supported uniform consumption rate $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$4 subject to schedule feasibility. FMCB, “fill-most-critical-buffer,” is event-driven: it identifies the most critical link and selects the configuration maximizing generation for that link, optionally breaking ties by the second-most-critical buffer (Mendez et al., 14 Mar 2026). Buffer dynamics are modeled as

$$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$5

The performance study uses a hexagonal network with 3 transmitters, 3 receivers, and 22 useful configurations. Physical-link generation rates are 9.6 kbps, 11.2 kbps, and 12.8 kbps depending on supporting receivers; link buffer capacity is 3.6 MB, corresponding to approximately 50 minutes of generation at 9.6 kbps; and the critical threshold is 5% of capacity, or 180 kB (Mendez et al., 14 Mar 2026). Under these conditions, MMAK selects an optimal cycle $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$6 with relative durations $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$7, supports uniform consumption above 36% of the lowest generation rate, corresponding to 3.49 kbps, balances buffers across links, and needs only 3 of 22 useful configurations. FMCB uses at least 4 configurations, often favoring boosted links, and supports below 25%, approximately 2.35 kbps, of the lowest generation rate, or approximately 70% of MMAK’s throughput (Mendez et al., 14 Mar 2026).

The framework is explicitly policy-aware. Administrators can specify priority lists, minimum buffer thresholds $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$8, minimum path availability, fairness weights, allowed configuration sets, and churn controls such as minimal dwell time and grace periods. Failure handling is event-driven: affected capacities are set to zero, invalid configurations are pruned, and new schedules are computed to preserve service continuity (Mendez et al., 14 Mar 2026).

5. Demand-driven orchestration in cooperative intelligent transport systems

In C-ITS, C-Koordinator denotes a demand-driven application management framework built on Kubernetes and ROS 2. The framework is intended for “deployment, reconfiguration, update, upgrade, and scaling of microservices” as well as on-demand provisioning of external supporting services such as a collective environment model (Zanger et al., 23 Sep 2025). Its operational premise is that multiple entities—vehicles, roadside units, edge nodes, and cloud—issue time-shifted and content-dependent demands, making static deployment wasteful or infeasible.

The control plane consists of an Event Detector with Operator Plugin, an Application Manager, and custom operators implemented with Kopf. The Event Detector analyzes C-ITS data streams for user-defined patterns and sends deployment requests by ROS 2 action call, with the Application Manager acting as action server. The Application Manager interprets the demand, maps it to a concrete topology of microservices and inter-node connections, adds domain-specific configuration such as topic selection and placement hints, and emits declarative Kubernetes custom resources. Operators watch those CRs, maintain bookkeeping for time-shifted multi-requester demands, and reconcile desired and current state by issuing Kubernetes primitives, Helm releases, and ROS 2 runtime reconfiguration actions (Zanger et al., 23 Sep 2025).

A key internal abstraction is requester-set bookkeeping. For each managed component, the operator maintains the set of requesters $$\mathrm{CPI} = \frac{\text{CPU cycles}}{\text{instructions}},$$9 and the aggregated requested configuration $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$0. Lifecycle states are Absent, Pending, Running, Reconfiguring, Draining, and Terminated, driven by requester-set changes and configuration differences (Zanger et al., 23 Sep 2025). The resulting behavior is deploy-only-what-is-missing, reconfigure shared services instead of duplicating them, and tear down components when the requester set becomes empty.

The data plane is ROS 2-centric. Microservices run as Kubernetes Pods and expose ROS 2 node interfaces with runtime-reconfigurable parameters. Intra-node and intra-pod communication uses DDS, while inter-node paths are made explicit by deployable communication client services such as MQTT bridges, which are themselves provisioned on demand (Zanger et al., 23 Sep 2025). Placement targets are expressed by node labels for edge and cloud, and offboard services can be instantiated when required.

The principal use case is collective environment perception. Vehicles $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$1 and infrastructure station $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$2 publish ego and sensor data; edge node $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$3 runs compute-intensive functions; cloud node $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$4 runs the Event Detector. The pipeline comprises on-demand ingestion, one object-detection service per active point-cloud source, and a fusion service at the edge. In the reported eight-step experiment, $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$5 approaching $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$6 triggers deployment of detection services for $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$7 and $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$8, fusion at $\widehat{\mathrm{CPI}} = f(\mathbf{x}),$9, and connections from $$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$0 and $$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$1 to $$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$2. As $$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$3, $$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$4, and $$\mathrm{CSI} = \frac{\Delta \mathrm{CPI}}{TH_{\mathrm{CPI}}}.$$5 approach, bookkeeping adds them as requesters, existing deployments are reused, fusion input topics are reconfigured, and only incremental connection services are created. As vehicles leave, shutdown requests remove them from requester sets; when a requester set becomes empty, the corresponding component is torn down, and when the last requester leaves, the entire application is shut down (Zanger et al., 23 Sep 2025).

Evaluation emphasizes functional correctness and qualitative efficiency rather than quantified resource savings. The paper reports that the sequence of deployments matches event sequences, shared services are not redeployed, fusion dynamically updates input topics without restarts where supported, and pod placement matches policy. At the same time, it explicitly states that quantitative CPU, latency, and network metrics were not reported (Zanger et al., 23 Sep 2025). Reliability relies on Kubernetes mechanisms such as liveness and readiness probes and rolling updates, while hard real-time guarantees are out of scope.

6. Comparative interpretation and recurrent platform patterns

Across the cited works, the designation “C-Koordinator Platform” covers distinct technical systems with different substrates, observability mechanisms, and optimization targets (Poss, 2013, Klotzbücher et al., 2013, Song et al., 24 Jul 2025, Mendez et al., 14 Mar 2026, Zanger et al., 23 Sep 2025).

Domain	Control entity	Coordination concern
Programming technologies	Objective criteria for coordination	Interface extensibility, customizable optimization goals, black-box componentization
Component-based robotics	Pure Coordinator plus Configurator	Commanding, configuring, and monitoring without embedding platform calls in the coordinator
Co-located microservice clusters	Add-on interference module over Koordinator and Kubernetes	CPI prediction, interference detection, CPU suppress, and pod eviction
Switched QKD networks	Switching Coordinator SDN application	Configuration-duration schedules for key generation, buffer balance, and failure response
C-ITS orchestration	Application Manager plus custom operators	Demand-driven deployment, reconfiguration, update, upgrade, scaling, and connection provisioning

Taken together, these works suggest a recurring architectural pattern: a relatively compact control plane maintains an explicit model of system state and triggers reconfiguration in a larger execution substrate. In robotics, the explicit state is the coordination model and configuration status; in microservice clusters, it is rolling telemetry and CPI predictions; in switched QKD, it is the global network model with buffers, configurations, and policies; in C-ITS, it is the bookkeeping state of requesters, topics, and placements (Klotzbücher et al., 2013, Song et al., 24 Jul 2025, Mendez et al., 14 Mar 2026, Zanger et al., 23 Sep 2025). This suggests that the strongest unifying property is not absence of computation, but explicit runtime control over component interaction, reconfiguration, and policy application, which is consistent with the objective coordination criteria of interface extensibility, customizable optimization goals, and black-box componentization (Poss, 2013).

The same comparison also shows that the platforms differ materially in their guarantees and maturity. The robotics pattern argues qualitative gains in determinism and robustness but reports no quantitative latency measurements (Klotzbücher et al., 2013). The microservice platform provides extensive production-scale metrics and explicitly defined intervention thresholds, but notes reduced predictive power for I/O-bound or accelerator-heavy workloads (Song et al., 24 Jul 2025). The QKD coordinator assumes that feasible links and useful configurations are given, leaving scalability of enumeration to future work (Mendez et al., 14 Mar 2026). The C-ITS framework demonstrates functional orchestration and reuse through bookkeeping, while deferring formal global optimization and quantitative benchmarking to future work (Zanger et al., 23 Sep 2025).

A plausible implication is that C-Koordinator is best understood as a family of coordination architectures whose concrete realization is domain-specific. In all cases, however, the central concern is the same: separate intent, policy, and orchestration logic from the mechanisms that execute computations, forward data, or activate resources, so that composite systems remain reconfigurable under changing runtime conditions.