{"id":"607d0b2d-17d9-4012-b9c6-17cb97a06ebe","arxiv_id":"2411.18503","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"A graph-based orchestrator uses Dijkstra's shortest path over a service graph to reconfigure control architectures at runtime based on a cost function.","lead":"This paper describes a way to let a control system, such as a water-level controller, pick its own internal configuration at runtime by treating each component as a service and choosing the best route through a graph. The authors demonstrate the approach on a three-tank system, showing that the configuration can change when new components appear or when the control goal changes.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The shortest-path architecture omits the control-input edge required by the Kalman filter services, so the selected path is not a functional closed-loop control system; this breaks the central claim as evaluated.","rationale":"The reader's weakest assumption about nested model complexity is real and worth testing, but the actuator-to-filter removal is a more immediate and internal correctness problem. The paper's own Kalman filter services require a control input that the transformed service graph never provides, so the shortest path computed by Algorithm 2 does not correspond to a functional control architecture. This is independent of the missing performance evaluation: even if runtime and accuracy were measured, the selected architecture would be infeasible as specified. The central claim that the method 'allows for dynamic changes in the control system architecture' therefore fails on the paper's own case study. A revised graph model would need to represent auxiliary inputs and feedback connections outside the simple path, or the orchestrator would need to add fixed side connections, and then the cost/optimality argument would need to be reworked. Because this is a structural flaw in the presented method, not a gap that additional experiments alone would close, the verdict should move from CONDITIONAL toward REJECT in the current form.","tokens_in":7911,"tokens_out":11106,"duration_ms":106821,"concrete_test":"Re-run Algorithm 1 and Algorithm 2 for the Table I services with the scenario-2 Kalman-filter/MPC path. For every selected service, enumerate its requirement interfaces and verify that each is matched by a guarantee on an incoming edge in the returned graph. The Kalman filter's τ_u requirement will have no matching incoming edge. Then deploy the returned path in a three-tank simulation: without a control-input edge into the Kalman filter, the state estimate, and therefore the MPC control signal, will be incorrect or undefined. If an external bus is assumed to supply τ_u, then the graph omits a communication dependency and the shortest-path cost claim is incomplete; either way, the architecture is not the path returned by the orchestrator.","verdict_should_be":"REJECT","load_bearing_attack":"Section II-A explicitly states that a filter requires functionality types τ_y and τ_u, and Figure 1 includes an edge from the actuator to the filter. However, transformation step 4 removes this edge 'as it introduces a cycle', and Algorithm 1 (lines 5–15) connects sensors to filters but never supplies the control input u to any filter node. The evaluation uses three Kalman filters, which require u to compute a state estimate. Algorithm 2 then sets the shortest path as the control system architecture, so a selected 'Kalman filter with medium model' has no incoming edge carrying u; its τ_u requirement is unmatched. This is not merely a missing simulation: the path returned by the orchestrator does not describe a deployable control loop. It also reveals a structural limitation: a single directed sensor-to-actuator path cannot represent services with multiple inputs or any feedback, exactly the Kalman-filter case used in the evaluation. This concern is more fundamental than the nested-model-complexity assumption, which is at least stated as an explicit design assumption; the loss of the filter's control-input connection is unacknowledged and breaks the correspondence between shortest path and feasible architecture on which the central claim rests.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a graph-based runtime orchestration method for service-oriented model-based control systems. Services (sensors, filters, controllers, actuators, models) are represented as nodes in a directed weighted graph; the orchestrator builds this graph (Algorithm 1) and selects the 'optimal' control system architecture as the shortest path from a new start node to a new target node using Dijkstra's algorithm (Algorithm 2). Edge weights come from a cost function (Eq. (2)) balancing computation cost and inaccuracy. The evaluation uses a three-tank system with hand-assigned service attributes to illustrate three scenarios: initial selection, addition of a new controller service, and a change in the cost-function weights. The paper claims that this method is more flexible, has lower computation time, and achieves higher accuracy than traditional configuration methods.","tokens_in":8087,"tokens_out":7167,"duration_ms":69966,"significance":"If the proposed method were sound as stated, it would be a useful contribution to runtime reconfiguration of service-oriented control systems: the service-graph formulation is clear, the algorithms are explicit and reproducible, and the dynamic handling of new services and changing objectives is a practical concern. The authors also make their key modeling assumption (nested model complexity) explicit, which is a strength. However, the central claim currently rests on two serious gaps: the graph transformation removes a required feedback input to filters, so the shortest path is not a functional control loop, and the evaluation contains no simulation, timing measurements, or baseline comparison, leaving the abstract's comparative performance claims unsupported. The contribution is therefore promising but not yet ready for publication without substantial revision.","major_comments":[{"comment":"The removal of the actuator-to-filter edge is not a harmless cycle-elimination step: it removes the τ_u input that the filter service explicitly requires. Figure 1 includes an edge from the actuator to the filter, and the service description states that a filter requires measured values of types τ_y and τ_u. Algorithm 1 connects filters only to sensors (lines 5–15), and no edge supplying u is ever added. Since the evaluation uses Kalman filters, which need u for state prediction, the shortest path returned by Algorithm 2 (e.g., Kalman filter with medium model plus MPC with medium model in scenario 2) does not describe a deployable closed-loop control system. The statement that 'the control loop remains closed' is therefore contradicted by the graph model. This is not a presentation issue: the correspondence between the computed shortest path and a feasible control architecture, on which the central claim rests, is broken. The authors need to revise the formulation, for example by adding required feedback edges as constraints or by explicitly separating fixed platform connections from the optimized service-selection edges.","section":"Section II-A (transformation step 4) and Algorithm 1"},{"comment":"The evaluation does not support the claims made in the abstract. The three scenarios only compute shortest paths in a hand-constructed graph with hand-assigned service attributes and weights; there is no simulation of the three-tank system, no timing measurements, no closed-loop accuracy results, and no comparison against the state-machine-based 'traditional configuration methods' mentioned in the abstract. Consequently, the abstract's assertions of 'lower computation time, and higher accuracy than traditional configuration methods' are unsupported. The authors should either add a real control-loop simulation with measured metrics (e.g., computation time, tracking error, settling time) and a baseline comparison, or substantially soften the claims to say that the method selects a path that minimizes a user-defined cost function.","section":"Section III (Evaluation)"},{"comment":"Defining optimality as the shortest path under the cost function makes the orchestration results in Section III consequences of the construction rather than independent findings. In particular, scenario 3, where changing α and β changes the selected path, is a direct result of the definition and not a validation of 'optimality' in any control-performance sense. This would be acceptable if the paper framed its contribution as a method for selecting an architecture with respect to a user-specified cost function, but the abstract and conclusion describe the selected architecture as 'optimal' and claim higher accuracy and lower computation time without linking these claims to the cost function or to measured performance. The claims should be narrowed to match what is actually shown.","section":"Section II-B and Definition 3"}],"minor_comments":[{"comment":"The cost function is written as the product of two vectors, but a cost value should be a scalar; it should presumably be a dot product or weighted sum, e.g., cost = α_comp x_comp + β_inacc y_inacc. The current notation is ambiguous.","section":"Section II-A, Eq. (2)"},{"comment":"The caption states 'βcomp = 100' and 'βcomp = 20' for scenarios 1, 2 and 3, but the variable defined in Eq. (2) is β_inacc; the notation should be corrected.","section":"Figure 3 caption"},{"comment":"The sentence illustrating compatible state vectors uses x_controller for both the controller and the filter output; using different symbols (e.g., x_hat for the filter estimate) would avoid confusion.","section":"Section II-A, after Definition 4"},{"comment":"Inside the model loop, 'Connect sensors to filter' is executed once for each model, which is correct if each filter-with-model is a distinct node, but the wording could be clarified to state that all sensors are connected to each newly added filter node.","section":"Algorithm 1, line 9"},{"comment":"The three-tank system is not described in enough detail: no model equations, parameters, or operating point are given, making it hard to assess the realism of the claimed costs and compatibility rules.","section":"Section III"},{"comment":"The shortest-path background cites overview works on graph theory; the authors should cite Dijkstra's 1959 paper directly, as it is the algorithm actually used.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is likely a work-in-progress report of a promising idea, but the feedback-edge gap and the absence of a real simulation are significant. The editor may also want to check the novelty relative to the authors' previous work [2] and the related MROS approach, since the incremental contribution currently lies mainly in the graph formulation and the Dijkstra-based selection, both of which need the above fixes to be credible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, here's my read on arXiv:2411.18503. The paper proposes a Dijkstra-based orchestrator for service-oriented control, which is a sensible extension of the authors' prior heuristic. The graph construction with model-compatibility grouping is clearly described, and framing optimality as shortest path with a tunable cost function is a reasonable abstraction. The idea has merit for runtime reconfiguration of control architectures.\n\nThe trouble is that the graph as constructed cannot represent a functioning Kalman filter. The authors state that a filter requires functionality types τ_y, τ_u, and τ_model, and Figure 1 shows an edge from the actuator to the filter carrying u. But transformation step 4 removes that edge to avoid cycles, and Algorithm 1 never adds it back. The selected shortest path from sensor to actuator has no way to deliver u to the filter. So the 'optimal architecture' returned by the orchestrator is not a closed-loop system. This is not a missing simulation; it is a structural gap in the model. The stress-test note is correct.\n\nThe evaluation is also thin: no simulation, no timing data, no baseline comparison. The abstract's claims about lower computation time and higher accuracy are not supported by the evidence presented. The cost values are hand-assigned, and the 'optimality' is a direct consequence of the cost function, so scenario 3 only shows that changing weights changes the selected path—a tautology.\n\nOn the positive side, the compatibility nesting assumption is at least stated explicitly, and the paper positions itself well against web-service composition literature. The orchestration algorithm itself is simple and correct within the (incomplete) graph.\n\nWho is this for? Researchers in service-oriented control who want a starting point for runtime adaptation. The paper would benefit from a serious revision that (a) allows feedback edges or otherwise represents the control input to filters, and (b) validates the method with actual simulation or hardware.\n\nFor peer review: I'd send it to referees, because the idea is relevant and the flaws are identifiable and fixable. But I'd expect a substantial rewrite before acceptance. The current version, as written, does not support the central claim.","headline":"A sensible orchestration idea undercut by an omitted feedback edge and weak validation; needs a structural fix and real evaluation.","tokens_in":8698,"tokens_out":3969,"would_cite":false,"duration_ms":32487,"reading_group":"yes","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A control system can rewire its own architecture at runtime by routing sensor-to-actuator data through the lowest-cost services.","keywords":["service-oriented architecture","graph-based orchestration","runtime adaptation","model-based control","shortest path","control system architecture","three-tank system","cost function optimization"],"falsifier":"Take a filter that estimates states $\\{x_1,x_2\\}$ and a controller that requires states $\\{x_2,x_3\\}$; each has complexity two on the paper's ordering, so the compatibility rule permits the edge, even though the filter's state vector does not contain the controller's required $x_3$. A simulation or experiment in which such a pair is selected and the controller fails to produce a valid input would show that the graph can certify an infeasible architecture.","tokens_in":7640,"feed_emoji":"⚙️","tokens_out":8936,"duration_ms":75615,"temperature":0.7,"pith_summary":"The paper tries to establish that a control system can treat its own architecture as an optimization problem: every component is a service, and the best architecture is the service composition of lowest cost under a user-defined objective. This makes adaptation a graph shortest-path computation rather than a finite list of preset configurations, so the architecture can change when new services appear or when the objective changes. The authors show on a three-tank level-control example that the orchestrator switches from PID to MPC when the MPC is added, and switches from an accurate Kalman filter to a cheap converter and PID when computation becomes the priority. The payoff would be control systems designed once that remain flexible and efficient through runtime reconfiguration.","feed_headline":"Shortest path through a service graph rewires a control system live","feed_subtitle":"Shortest-path search picks the cheapest filter–controller–actuator combination whenever objectives or services change.","key_machinery":"The load-bearing mechanism is the transformed service graph. The orchestrator collapses each filter or controller together with every model it can use into separate nodes, adds a fixed start node connected to all sensor nodes and a fixed target node collecting all actuator nodes, drops the fixed process service and any edges that would create cycles, and then assigns each incoming edge a non-negative weight given by the cost function. Compatibility between filters and controllers is enforced by the rule that an edge exists only when the filter's model complexity is greater than or equal to the controller's model complexity. The shortest-path search on this graph returns the lowest-cost architecture.","core_discovery":"On the paper's own terms, the discovery is a formulation: at any instant the optimal control system architecture is defined as the shortest path in a directed service graph from a fixed start node through sensor, filter/model, controller/model, and actuator nodes to a fixed target node, with edge weights given by the cost function of Eq. (2), $c = \\alpha_{\\mathrm{comp}} x_{\\mathrm{comp}} + \\beta_{\\mathrm{inacc}} y_{\\mathrm{inacc}}$, where $x_{\\mathrm{comp}}$ is the service's computation factor and $y_{\\mathrm{inacc}}$ its model inaccuracy. The orchestrator builds this graph from the current service registry and reruns the shortest-path algorithm whenever a service is added, removed, or updated or whenever the cost function changes. The three-tank experiments show three consequences of this formulation: adding a previously unknown MPC service at runtime changes the chosen controller even though the objective is unchanged; reweighting the cost function from accuracy-dominated to computation-dominated switches the architecture; and the adaptive architecture is reported to have lower computation time and higher accuracy than fixed configurations.","pith_inferences":["Because edge weights are generic, the same graph could absorb other objectives beyond computation time and inaccuracy, such as communication latency or energy, by adding their costs to the edge weights; this is a direct extension the paper does not pursue.","If the nested-state assumption fails in practice, the orchestrator could instead prune edges using the functionality-type requirements and guarantees already present in the service model, avoiding infeasible paths without altering the shortest-path machinery.","The weighting coefficients $\\alpha_{\\mathrm{comp}}$ and $\\beta_{\\mathrm{inacc}}$ could be scheduled online as functions of system state, for example favoring accuracy near unsafe regions, turning the orchestrator into a policy that tracks a time-varying objective.","A concrete benchmark with real network latency and non-nested models would reveal how often the graph-certified optimal path is actually implementable, separating the formulation's reach from its domain of validity."],"forward_implications":["A control architecture can legally change its sensor-filter-controller-actuator path at runtime without shutting down or manual redesign, because the orchestrator just reruns the same shortest-path routine.","Adding a service that was not known at design time can immediately improve the closed-loop behavior, since the next orchestration cycle may route through it; scenario 2 shows the MPC replacing the PID under an unchanged cost function.","Changing the system objective is reduced to changing two scalar weights, and the orchestrator then produces the correspondingly different architecture; scenario 3 shows the converter/PID path winning when computation time dominates.","The method inherits the efficiency of a standard shortest-path algorithm, so the adaptation decision can be made quickly enough for the real-time setting that distinguishes control service-oriented architecture from web-service orchestration."],"supporting_citations":[{"why":"Defines service-oriented architecture, service composition, and orchestration, which the paper formalizes for control systems.","marker":"[1]"},{"why":"The previous service-oriented model-based control implementation whose heuristic orchestrator this paper replaces with graph-based cost optimization.","marker":"[2]"},{"why":"Provides the service model with interfaces, requirements, guarantees, and functionality types used to define service compatibility.","marker":"[3]"},{"why":"Demonstrates graph-based service composition for web services, the precedent for using shortest-path style search to select services.","marker":"[10]"},{"why":"Supplies the graph-theory background and the shortest-path algorithm that computes the optimal path in the service graph.","marker":"[20]"}],"fun_headline_variants":["Shortest-path search picks the cheapest control setup at runtime","Runtime graph shortest path rewires control architecture on the fly","Optimal control path picked live via service graph weights","Service graph shortest path adapts control systems to cost changes","Rewire control loops on the fly with graph shortest-path selection"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole construction depends on the assumption that every model of higher complexity contains all states of every lower-complexity model as a subset; if real models are not nested in this way, the compatibility rule can draw edges between services that cannot actually work together, and the shortest path may be a nonfunctional control architecture.","fun_headline_variants_meta":{"raw":{"variants":["Shortest-path search picks the cheapest control setup at runtime","Runtime graph shortest path rewires control architecture on the fly","Optimal control path picked live via service graph weights","Service graph shortest path adapts control systems to cost changes","Rewire control loops on the fly with graph shortest-path selection"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00041,"raw_usage":{"total_tokens":2113,"prompt_tokens":920,"completion_tokens":1193,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":536,"completion_tokens_details":{"reasoning_tokens":1112}},"tokens_in":536,"tokens_out":1193,"duration_ms":8438,"temperature":1.0,"reasoning_tokens":1112,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T11:07:42.093897+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a filter that estimates states $\\{x_1,x_2\\}$ and a controller that requires states $\\{x_2,x_3\\}$; each has complexity two on the paper's ordering, so the compatibility rule permits the edge, even though the filter's state vector does not contain the controller's required $x_3$. A simulation or experiment in which such a pair is selected and the controller fails to produce a valid input would show that the graph can certify an infeasible architecture.","supporting_citations":[{"cited_title":"Erl, ”Service-Orientated Architecture: Concepts, Technology, & Design,” in 4th ed","cited_arxiv_id":null,"evidence_quote":"Defines service-oriented architecture, service composition, and orchestration, which the paper formalizes for control systems."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The previous service-oriented model-based control implementation whose heuristic orchestrator this paper replaces with graph-based cost optimization."},{"cited_title":"Kampmann, B","cited_arxiv_id":null,"evidence_quote":"Provides the service model with interfaces, requirements, guarantees, and functionality types used to define service compatibility."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Demonstrates graph-based service composition for web services, the precedent for using shortest-path style search to select services."},{"cited_title":"Anandhan, K","cited_arxiv_id":null,"evidence_quote":"Supplies the graph-theory background and the shortest-path algorithm that computes the optimal path in the service graph."}],"review_version":1}