Graph-Based Orchestration of Service-Oriented Model-Based Control Systems

Bassam Alrifaee; Bianca Atodiresei; Hazem Ibrahim; Julius Beerwerth; Lorenz D\"orschel

REVIEW 3 major objections 6 minor 20 references

Graph-Based Orchestration of Service-Oriented Model-Based Control Systems

T0 review · 3 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A control system can rewire its own architecture at runtime by routing sensor-to-actuator data through the lowest-cost services.

desk verdict A sensible orchestration idea undercut by an omitted feedback edge and weak validation; needs a structural fix and real evaluation. read the letter →

arxiv 2411.18503 v1 pith:ZUZIR4XG submitted 2024-11-27 eess.SY cs.SY

Julius Beerwerth , Hazem Ibrahim , Bianca Atodiresei , Lorenz Dörschel , Bassam Alrifaee This is my paper · ORCID

classification eess.SYcs.SY

keywords service-orientedarchitecturegraph-basedorchestrationruntimeadaptationmodel-basedcontrolshortestpathsystemthree-tankcostfunctionoptimization

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

The 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.

On 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.

Who 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.

For 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.

Referee Report

3 major / 6 minor

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.

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 (3)

[Section II-A (transformation step 4) and Algorithm 1] 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 III (Evaluation)] 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 II-B and Definition 3] 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.

minor comments (6)

[Section II-A, Eq. (2)] 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.
[Figure 3 caption] 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 II-A, after Definition 4] 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.
[Algorithm 1, line 9] 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 III] 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.
[References] 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.

Circularity Check

2 steps flagged · score 4.0 of 10

Optimality is stipulated as the shortest path in Definition 3, so the evaluation's 'optimal' selections and accuracy claims reduce to the hand-assigned cost function; the graph-construction core is independent, but the optimality demonstration is definitional.

self definitional [Section II-A, Definition 3; Algorithm 2 (line 2)]
"An optimal control system architecture is defined as the service composition that has the lowest cost based on a predefined cost function. In our case, this is represented by the shortest path from the sensor to the actuator. ... Definition 3 (Optimal Control System Architecture). We define optimality in SOA as the shortest path in the service graph based on the cost function."

The term 'optimal architecture' is stipulated, not derived from an external control-theoretic criterion: it is defined to be the shortest path under Eq. (2). Since every edge weight is assigned from the hand-set values in Table I and Eqs. (3)-(4), Dijkstra's output is, by construction, the argmin of those inputs. The evaluation's observation that changing alpha and beta changes the selected path (scenario 3) is therefore a direct consequence of the definition, not empirical evidence of optimality. The independent content lies in the graph construction and compatibility rule, but the reported 'optimal' choices add no information beyond the chosen weights.
other [Section II-A, 'Remark (Accuracy vs Inaccuracy)'; Section III, Eqs. (3)-(4) and Table I]
"Dijkstra's algorithm finds paths with the lowest cost, so cost function variables must reflect that principle: lower values indicate better outcomes. To address this, we use inaccuracy (the inverse of accuracy). ... The inaccuracy y_inacc is linked to the model used: lower inaccuracy implies a more complex model. To compute the inaccuracy of a service's model, we make following assumptions: ... If the service is a controller then: x_comp = i^2 ... If the service is a filter, then: x_comp = j^3 ..."

Accuracy is not measured on the three-tank plant; it is operationalized as the hand-assigned y_inacc values in Table I and the ad hoc powers in Eqs. (3)-(4). The abstract's claim that the method gives 'higher accuracy' is therefore a restatement of the authors' own cost inputs: a path is called more accurate exactly when it has a smaller pre-assigned inaccuracy number. This is an input renaming the evaluation result, not a first-principles or measured outcome.

full rationale

Definition 3 stipulates that 'optimal control system architecture' means 'shortest path under Eq. (2)'. Because the edge weights are assigned from the hand-set values in Table I and Eqs. (3)-(4), the paths in Fig. 3 are arithmetic consequences of those inputs; scenario 3's path switch after changing alpha and beta is a direct consequence of the definition, not an external validation. I therefore flag the optimality claim as self-definitional. Similarly, 'accuracy' is introduced as a cost variable ('we use inaccuracy (the inverse of accuracy)') and the abstract's 'higher accuracy' claim is a restatement of the assumed y_inacc ordering rather than a measured plant result. These two reductions are partial circularity, so the score is 4. The graph-construction algorithm, the model-complexity compatibility rule, and the dynamic re-run procedure are independent contributions and are not circular. A separate soundness concern, not counted as circularity, is that transformation step 4 removes the actuator-to-filter edge and Algorithm 1 never adds such an edge, so the Kalman filter's required tau_u input is not represented in the selected path; the path is not a closed control loop under Definition 1.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim rests on hand-assigned cost parameters and a simplifying compatibility assumption. No new physical entities are introduced. The cost function and its weights are free parameters, while the model-complexity nesting and the removal of the process service are domain assumptions that shape the graph and the optimal path.

free parameters (6)

alpha_comp (computation weighting) = 1 (scenarios 1-2), 1000 (scenario 3)
Chosen by hand to demonstrate different objective priorities; not derived from data.
beta_inacc (inaccuracy weighting) = 100 (scenarios 1-2), 20 (scenario 3)
Chosen by hand to demonstrate different objective priorities; not derived from data.
Service xcomp and yinacc values (Table I) = Sensor (2,9), Converter (1,11), Model Low (2,10), Model Medium (5,5), Model High (10,1), PID (1,11), Actuator (2,8)
Hand-assigned proxies for computation time and inaccuracy; no measurements or calibration provided.
Exponent in filter cost (j^3) = 3
Arbitrary choice in Eq. (4) relating filter computation factor to model inaccuracy; no justification provided.
Exponent in MPC cost (i^2) = 2
Arbitrary choice in Eq. (3) relating controller computation factor to model inaccuracy; no justification provided.
Constraints i>1 and j>1 = excludes high-complexity model
Ad hoc restrictions in Eqs. (3)-(4) that remove the high-complexity model from consideration, affecting the selected architecture.

assumptions (5)

domain assumption Model complexity is determined by the dimension of the system matrix A
Used to categorize models and enforce compatibility; stated in Section II-A, Definition 4.
domain assumption A filter with higher model complexity is compatible with a controller of lower or equal complexity, and every higher complexity state includes all lower complexity states
Simplifies compatibility to a complexity inequality; stated in Section II-A. If states are not nested, the constraint is invalid.
standard math Dijkstra's algorithm finds the shortest path in a weighted graph with non-negative weights
Implicit in applying Dijkstra; cited from [20].
standard math Edges that introduce cycles can be omitted from shortest-path search because weights are non-negative
Used in graph transformation step 4 in Section II-A.
domain assumption The process service (state reference) is fixed and can be removed without affecting optimality
Assumed in Section II-A step 2; if the process could change, the graph would need re-evaluation.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Graph-Based Orchestration of Service-Oriented Model-Based Control Systems." pith.science (2026). https://pith.science/paper/ZUZIR4XG

@misc{pith2026241118503,
  author       = {Pith},
  title        = {Pith review of: Graph-Based Orchestration of Service-Oriented Model-Based Control Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZUZIR4XG}},
  note         = {Machine review of arXiv:2411.18503}
}

read the original abstract

This paper presents a novel graph-based method for adapting control system architectures at runtime. We use a service-oriented architecture as a basis for its formulation. In our method, adaptation is achieved by selecting the most suitable elements, such as filters and controllers, for a control system architecture to improve control systems objective based on a predefined cost function. Traditional configuration methods, such as state machines, lack flexibility and depend on a predefined control system architecture during runtime. Our graph-based method allows for dynamic changes in the control system architecture, as well as a change in its objective depending on the given system state. Our approach uses a weighted, directed graph to model the control system elements and their interaction. In a case-study with a three-tank system, we show that by using our graph-based method for architecture adaptation, the control system is more flexible, has lower computation time, and higher accuracy than traditional configuration methods.

Figures

Figures reproduced from arXiv: 2411.18503 by the authors.

**Figure 2.** Example of control system architecture graph with start and target nodes, and instantiated service types. Edges show varying model complexities. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Control system architecture graph and the shortest path based on the values from Table I, the cost function from Eq. (2) with [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 20 canonical work pages

[1]

Erl, ”Service-Orientated Architecture: Concepts, Technology, & Design,” in 4th ed

T. Erl, ”Service-Orientated Architecture: Concepts, Technology, & Design,” in 4th ed. Prentice Hall , 2005

work page 2005
[2]

O. Greß, M. Zimmer, A. Kampmann, L. D ¨orschel, and B. Alrifaee, ”Service-Oriented Model-based Control - Dynamic Software for Dy- namic Systems,” in in 2024 European Control Conference (ECC) , pp. 3299-3305, 2024

work page 2024
[3]

Kampmann, B

A. Kampmann, B. Alrifaee, M. Kohout, A. W¨ ustenberg, T. Woopen, M. Nolte, L. Eckstein and S. Kowalewski, ”A Dynamic Service-Oriented Software Architecture for Highly Automated Vehicles,” in 2019 IEEE Intelligent Transportation Systems Conference (ITSC) , pp.2101-2108, 2019

work page 2019
[4]

Kampmann, A

A. Kampmann, A. W¨ ustenberg, B. Alrifaee and S. Kowalewski, ”A Portable Implementation of the Real-Time Publish-Subscribe Protocol for Microcontrollers in Distributed Robotic Applications,” in2019 IEEE Intelligent Transportation Systems Conference (ITSC) , pp. 443-448, 2019

work page 2019
[5]

Kampmann, M

A. Kampmann, M. L¨ uer, S. Kowalewski and B. Alrifaee, ”Optimization- based Resource Allocation for an Automotive Service-oriented Software Architecture,” in 2022 IEEE Intelligent Vehicles Symposium (IV), Aachen, Germany, 2022 , pp. 678-687, 2022

work page 2022
[6]

Fu, ”Switching Adaptive Control,” in Encyclopedia of Systems and Control, J

M. Fu, ”Switching Adaptive Control,” in Encyclopedia of Systems and Control, J. Baillieul and T. Samad, Eds. Cham: Springer International Publishing, pp. 2261–2266, 2021

work page 2021
[7]

T. A. Johansen and T. I. Fossen, ”Control allocation—A survey,” Automatica, vol. 49, no. 5, pp. 1087–1103, May 2013

work page 2013
[8]

Nakagawa, A

H. Nakagawa, A. Ohsuga, and S. Honiden, ”Towards Dynamic Evolution of Self-Adaptive Systems Based on Dynamic Updating of Control Loops,” in2012 IEEE Sixth International Conference on Self-Adaptive and Self-Organizing Systems, pp. 59-68, 2012

work page 2012

Show all 20 references

[9]

Bozhinoski, M

D. Bozhinoski, M. Garzon Oviedo, N. Hammoudeh Garcia, H. Desh- pande, G. van der Hoorn, J. Tjerngren, A. Wasowski, C. Hernandez Corbato, ”MROS: runtime adaptation for robot control architectures,” in Advanced Robotics, pp. 502-518, 2022

2022
[10]

Z. Tian, C. Zhang, J. Xiao, and S. Liang, ”A Graph-Based Service Composition Method for Science and Technology Resources,” inHuman Centered Computing. HCC 2021. Lecture Notes in Computer Science , vol. 13795, 2022

2021
[11]

W. Bi, J. Ma, X. Zhu, W. Wang, and A. Zhang, ”Cloud service selection based on weighted KD tree nearest neighbor search,” in Applied Soft Computing, vol. 131, pp. 109780, 2022

2022
[12]

Alhosaini, X

H. Alhosaini, X. Wang, L. Yao, Y. Chen, and G. Xu, ”Caching Hierar- chical Skylines for Efficient Service Composition on Service Graphs,” in 2022 IEEE International Conference on Services Computing (SCC) , pp. 1-9, 2022

2022
[13]

J. Wu, J. Zhang, Y. Zhang, and Y. Wen, ”Constraint-aware and multi- objective optimization for micro-service composition in mobile edge computing,” in Software: Practice and Experience , vol. 54, no. 9, pp. 1596-1620, 2024

2024
[14]

Zhang, K

B. Zhang, K. Wen, J. Lu, and M. Zhong, ”A top-K QoS-optimal service composition approach based on service dependency graph,” in Journal of Organizational and End User Computing (JOEUC) , vol. 33, no. 3, pp. 50-68, 2021

2021
[15]

T ¸ uc˘ar, and P

L. T ¸ uc˘ar, and P. Diac, ”Semantic web service composition based on graph search,” in Procedia Computer Science , vol. 126, pp. 116-125, 2018

2018
[16]

J. Li, M. Zhu, M. Yu, Y. Yan, and L. Cui, ”Service composition based on pre-joined service network in graph database,” inInternational Journal of Web and Grid Services , vol. 16, no. 4, pp. 422-440, 2020

2020
[17]

R. C. Dorf and R. H. Bishop, ”Modern Control Systems, Global Edition,” 14th ed. Pearson, 2011

2011
[18]

Riaz and K

F. Riaz and K. M. Ali, ”Applications of Graph Theory in Computer Science,” in Third International Conference on Computational Intel- ligence, Communication Systems and Networks , Bali, Indonesia, pp. 142-145, 2011

2011
[19]

Chen, ”Applied Graph Theory,” in Elsevier, 2012

W.K. Chen, ”Applied Graph Theory,” in Elsevier, 2012

2012
[20]

Anandhan, K

P. Anandhan, K. Uma, and J. Anuradha, ”An overview of application of graph theory,” in International Journal of ChemTech Research , vol. 9, no. 2, pp. 242-248, 2016

2016

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

Erl, ”Service-Orientated Architecture: Concepts, Technology, & Design,” in 4th ed

T. Erl, ”Service-Orientated Architecture: Concepts, Technology, & Design,” in 4th ed. Prentice Hall , 2005

work page 2005

[2] [2]

O. Greß, M. Zimmer, A. Kampmann, L. D ¨orschel, and B. Alrifaee, ”Service-Oriented Model-based Control - Dynamic Software for Dy- namic Systems,” in in 2024 European Control Conference (ECC) , pp. 3299-3305, 2024

work page 2024

[3] [3]

Kampmann, B

A. Kampmann, B. Alrifaee, M. Kohout, A. W¨ ustenberg, T. Woopen, M. Nolte, L. Eckstein and S. Kowalewski, ”A Dynamic Service-Oriented Software Architecture for Highly Automated Vehicles,” in 2019 IEEE Intelligent Transportation Systems Conference (ITSC) , pp.2101-2108, 2019

work page 2019

[4] [4]

Kampmann, A

A. Kampmann, A. W¨ ustenberg, B. Alrifaee and S. Kowalewski, ”A Portable Implementation of the Real-Time Publish-Subscribe Protocol for Microcontrollers in Distributed Robotic Applications,” in2019 IEEE Intelligent Transportation Systems Conference (ITSC) , pp. 443-448, 2019

work page 2019

[5] [5]

Kampmann, M

A. Kampmann, M. L¨ uer, S. Kowalewski and B. Alrifaee, ”Optimization- based Resource Allocation for an Automotive Service-oriented Software Architecture,” in 2022 IEEE Intelligent Vehicles Symposium (IV), Aachen, Germany, 2022 , pp. 678-687, 2022

work page 2022

[6] [6]

Fu, ”Switching Adaptive Control,” in Encyclopedia of Systems and Control, J

M. Fu, ”Switching Adaptive Control,” in Encyclopedia of Systems and Control, J. Baillieul and T. Samad, Eds. Cham: Springer International Publishing, pp. 2261–2266, 2021

work page 2021

[7] [7]

T. A. Johansen and T. I. Fossen, ”Control allocation—A survey,” Automatica, vol. 49, no. 5, pp. 1087–1103, May 2013

work page 2013

[8] [8]

Nakagawa, A

H. Nakagawa, A. Ohsuga, and S. Honiden, ”Towards Dynamic Evolution of Self-Adaptive Systems Based on Dynamic Updating of Control Loops,” in2012 IEEE Sixth International Conference on Self-Adaptive and Self-Organizing Systems, pp. 59-68, 2012

work page 2012