A Modular Active–Reactive AAS Architecture for Mass-Customized Production: Validation on an Industrial-Grade Robotic Screwdriving Demonstrator

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This article offers an interesting approach to implementing the Asset Administration Shell architecture for mass production customization systems. From the perspective of distributed systems engineering and technical computer science, this text presents an interesting application solution. The issues addressed are current and relevant to digital twin systems. However, a thorough analysis of the material reveals a number of weaknesses and methodological simplifications requiring improvement. The study is a feasibility study.

Remarks:
1) I propose to describe in more detail the basis and scope of the model selection for the research problem.
2) Clarification of the research objectives and hypotheses.
3) What does an experiment verifying the integrity of the reactive layer during rollout involve?
4) Is a comparison table required with current architectures?
5) What are the definitions of active skills and active steps?
6) How would the presented solution compare to a comparative experiment with a monolithic architecture or another proactive architecture? 7) Clarify the LLM dataset and the process of establishing the reference truth?
8) Compare the presented model with a deterministic constraint validator.
9) What features of the presented model represent a unique approach in the field under study?
10) Why do the component shares in Table 2 sum to 77.1% (42 + 8.4 + 19 + 1.4 + 6.3), and the "Total" rows sum to 100%?
11) Section 6 "Patents" is empty?

Author Response

Comments 1: I propose to describe in more detail the basis and scope of the model selection for the research problem.

Response 1: 

Thank you for this observation. We agree that the manuscript stated the choice of model without justifying it. We have added a new subsection, Section 2.9, Model Selection Protocol, reporting the selection trajectory that preceded the reported campaign.

Each candidate configuration — a combination of prompt strategy and language model — was executed over a versioned test suite and characterised by two metrics, reported separately. Structural conformity (CE) is the fraction of inferences returning a schema-conformant JSON verdict, which measures whether the output can be consumed by the provider state machine at all. F1 over the capable/not-capable decision measures classification quality; it was preferred over accuracy because the early suites were unbalanced and because false positives and false negatives carry different operational consequences in a production cell. The trajectory is now reported in Table 2:

Configuration	Model	Cases × rep.	Accuracy (%)	CE (%)	F1 (%)
Direct pattern matching	GPT-4.1 Nano	132 × 10	54.40	99.54	65.22
Structured prompt	GPT-4.1 Nano	132 × 10	65.40	99.70	45.87
Structured prompt with deterministic tools	GPT-4.1 Nano	132 × 10	46.50	92.50	58.00
Structured prompt, functional suite	GPT-4.1 Nano	74 × 10	66.40	96.22	74.30
Embedded reasoning	GPT-5	60 × 2	81.70	100.00	81.97
Embedded reasoning, revised submodel	GPT-5	134 × 5	94.60	100.00	88.68
Open-weight reasoning (selected)	GPT-OSS-20B	145 × 5	96.70	100.00	92.00

The subsection reports three findings that drove the selection: prompt structure alone did not resolve the task; supplying deterministic tools degraded every metric (see also our response to Comments 8); and only models with embedded reasoning brought the task into a usable range.

The final configuration was chosen on operational rather than statistical grounds. GPT-5 reached the required decision quality but averaged 24 s per evaluation and occasionally exceeded 5 min, which is incompatible with production-time coordination, and it is reachable only through a proprietary API. GPT-OSS-20B is open-weight and can be hosted inside the plant boundary, which also avoids transmitting capability declarations — process know-how such as torque envelopes and cycle times — to a third-party service.

We also state two limitations of the protocol explicitly: the test suite evolved across the trajectory, so the rows of Table 2 document a sequence of engineering decisions rather than a single factorial experiment; and from the migration to reasoning models onwards the generator seed was deliberately released rather than fixed, so that repeated executions of the same case expose the variability of the model instead of masking it.

This last point corrects an error in the submitted version, which stated that inference used "temperature set to zero and a fixed seed". That statement was incorrect: a fixed seed was used only in early development and was deliberately abandoned, because the evaluation protocol measures how often a model succeeds across repetitions of the same case. The sentence has been replaced.

This change can be found on pp. 11–12, Section 2.9, l. 243–276, with Table 2 on p. 12; the corrected sentence is on p. 12, Section 2.10, l. 279–287.

Note on table numbering. This table is Table 2 in the revised manuscript; see the note in our response to Comments 5 for the full mapping of the renumbered tables.

Comments 2: Clarification of the research objectives and hypotheses.

Response 2: 

We agree, and addressing this comment led us to correct a substantive imprecision as well as a presentational one. Section 2.1 previously stated the objective in narrative form with no hypotheses, and it stated the central property symmetrically — that the active layer can be redeployed without changing the reactive layer — which is more general than what the architecture actually provides. The subsection has been rewritten as Section 2.1, Research Design, Objectives and Hypotheses.

Preservation is structural, and is now defined as such. The two layers do exchange data at run time, so the earlier wording was not accurate. During an active-layer rollout, no submodel of the reactive AAS is removed or re-typed, no submodel element is added, removed or re-typed, and no semanticId is modified; introducing a variant adds submodels and modifies none. Element values do change by design: the active part of the requester and the active part of the provider each write the state produced by their decision algorithms back into their own reactive shell, the step status of the ActiveSteps submodel being the main example. This write-back is what keeps process state observable to any standard AAS consumer through the canonical interfaces, without that consumer knowing that an active layer exists. We have accordingly replaced the phrase "leaving the reactive layer untouched" wherever it appeared.

The two sides are now treated separately, because they carry different requirements. On the requester side, product variants come into existence on demand: a product becomes a type-3 AAS when it enters the line and ceases to exist once its order is complete, so instantiation cost and deployment latency dominate. On the provider side, resources are long-lived and are not redeployed at that rate; what matters there is that the active part does not depend on which submodels implement each function, so that it can be generated instead of written.

Three falsifiable hypotheses follow, each bound to reported measurements:

• H1 (requester side) — variants are maintained as modelling files in a standard AAS server and their active part is instantiated on demand, so introducing a variant needs only an active-layer package and its ActiveSteps submodel, with no structural change to the reactive submodels already held in the server. Assessed through t_deploy, S_deploy, and the structural comparison.
• H2 (provider side) — the ActiveSkills submodel makes the provider core agnostic to which capability and skill submodels implement each function, so one provider-core image is reused across resources and what a scenario needs of its own is confined to the services the core calls. Assessed by operating one provider-core image, instantiated once per robot, alongside the capability, feasibility and working services of the screwing scenario, and by updating those working services with no restart of the reactive layer.
• H3 (both sides) — the negotiation sustains latency and decision quality compatible with asynchronous production coordination. Assessed through t_cfp, t_accept, t_cycle, and through the structural conformity and F1 of the capability-checking service.

Each hypothesis is answered in Section 3.6, Assessment of the Hypotheses, for which the submitted version had no equivalent. H1 and H3 are reported as supported within a stated envelope. H2 is reported as only partially supported: the reuse demonstrated is of the core and not of the whole active layer, since a new scenario still calls for its own domain services, and the automatability that follows from the agnosticism is a consequence of the design and not a measurement. The tool that would generate the active part from the submodels is under construction and is stated as an implication outside the evaluation scope.

This change can be found on pp. 2–3, Section 2.1, l. 60–117, and the hypotheses are answered on p. 22, Section 3.6, l. 572–596. The dependent rewordings, which replace "untouched" and "without touching" with the structural formulation, are on p. 1, Abstract; p. 2, Section 1, l. 41–45; p. 4, Section 2.2, l. 133–138; pp. 6–7, Section 2.4; and p. 8, Section 2.6. No occurrence of the earlier wording remains.

Comments 3: What does an experiment verifying the integrity of the reactive layer during rollout involve?

Response 3: 

We thank the reviewer for this question, which exposed a genuine imprecision rather than a missing measurement. The submitted manuscript used "unchanged" and "untouched" to carry three distinct properties at once, which made the claim unverifiable as stated and made the reviewer's question unanswerable as posed. Section 2.1 now separates them.

Additive upgrade. An asset that already exposes a reactive (type-2) AAS becomes type-3 by addition. The upgrade inserts a pair of submodels on each side: on the requester side an ActiveSteps submodel and the submodel declaring the capability the product needs; on the provider side an ActiveSkills submodel and the submodel declaring the capability the resource offers. No existing submodel is refactored. We now also state explicitly what the upgrade costs, which the submitted version left implicit, and that the cost is not symmetric. On the provider side, inserting the submodels and attaching the active layer calls for one restart of the reactive part, because the reactive AAS of a resource loads its submodel set at start-up, so a new submodel becomes visible only after a restart; that is a one-time cost per resource. On the requester side no restart is needed, since product submodels are inserted through the standardized API of the BaSyx server while it keeps serving.

Structural stability. Following the upgrade, active-layer rollouts introduce no structural change to existing submodels: no submodel is removed or re-typed, no submodel element is added, removed or re-typed, and no semanticId is modified. Element values do change, and by design: the active parts of both the requester and the provider write the state produced by their decision algorithms back into their own reactive shell, the step status of ActiveSteps being the main example. That write-back is what keeps process state observable to any standard AAS consumer through the canonical interfaces.

Service continuity. Once an asset is type-3, the active layer can be updated, replaced or rolled back with no restart of the reactive layer, so consumers reading the reactive AAS are not interrupted.

This separation also distinguishes two events that the submitted manuscript conflated. An upgrade happens once per asset and inserts two submodels; on the provider side it costs one restart. A rollout happens continuously and leaves every submodel already present structurally unchanged, with no restart of the reactive layer. The reviewer asked about integrity during rollout, and it is during rollout that the property holds most strongly; the restart belongs to the upgrade, and there only to the provider side.

Section 3.1 now reports what was observed in the demonstrator against each of the three properties, rather than asserting preservation in general terms.

We note that verifying structural stability instrumentally — by comparing canonical structural fingerprints of every submodel before and after each rollout, excluding element values — is straightforward with the standardized AAS API, and we state it as the natural way to audit the property at scale. It was not required to answer the present question, since structure is fixed at modelling time and rollouts do not touch modelling artefacts.

This change can be found on pp. 2–3, Section 2.1, l. 65–98 (the three properties), p. 3, l. 101–113 (H1 and H2, whose assessment clauses were adjusted accordingly), and pp. 15–16, Section 3.1, l. 406–417 (the observations).

Comments 4: Is a comparison table required with current architectures?

Response 4: 

Yes, and we thank the reviewer for the suggestion. Table 9 now positions the proposal against the families of related work already cited, along five dimensions: proactive type-3 behaviour, additive reactive preservation, independent active redeploy, submodel-level contract, and physical validation.

We interpreted the comment as a request for a qualitative positioning table against the related work, since a performance comparison against competing implementations would require building and instrumenting a second complete system on the same cell, which is outside the scope of a feasibility study. If the reviewer intended the latter, we would welcome the clarification and address it in a further revision; a design for such an experiment is stated in our response to Comments 6.

Two points about how the table is built. The entries record what each cited work reports as its primary focus, which the caption states, since a full capability audit of those systems is beyond what their papers support. And the last column is labelled physical validation rather than industrial deployment, with the caption recording that the demonstrator for the present work is built to industrial standards but is not a live production line.

We have also added a paragraph stating the dimension on which the proposal would not score well: the two submodel templates are not IDTA-standardized, so the contract is portable within an implementation and not across vendors, and standardizing them is stated as future work.

This change can be found on pp. 23–24, Section 4, l. 602–625, with Table 11 on p. 24.

Comments 5: What are the definitions of active skills and active steps?

Response 5: 

We agree that a manuscript whose central contribution is a pair of submodels must define them formally, and acting on this comment led us to correct two substantive errors in the descriptions themselves.

The submitted version described both submodels as carrying content they do not carry. The Introduction and Section 2.2 stated that the ActiveSkills submodel "declares decision services and negotiation endpoints", and Section 2.4 stated that the ActiveSteps submodel encodes "preconditions, torque bounds, sequencing rules, and fallbacks". Neither is the case. Both submodels are pure indirections. Process parameters such as torque bounds, depth limits and setup coordinates are held in the referenced capability submodels, and endpoints, retry and timeout policies and QoS targets belong to the deployment. All three descriptions have been corrected and now agree with the specification in Table 1.

This minimalism is the mechanism rather than an omission: because a provider core only resolves a reference and reads the capability submodel it finds, it needs no knowledge of which capabilities exist, which is what allows a single image to serve resources with different declarations.

Both templates are now specified in Table 1 (p. 7): for ActiveSteps, the Step collection with multiplicity 1..n containing ReferenceToSubmodel, AllowBidding, StepStatus and ProductCost; for ActiveSkills, the Skills container with a Skill collection of multiplicity 1..n, each carrying ReferenceToSubmodel.

We also state their provenance, which the submitted version left ambiguous. Neither submodel is IDTA-standardized. Both were defined for this architecture and are documented internally. They were built as Submodel Templates following the modelling rules of the IDTA metamodel, with element multiplicity declared through template qualifiers, and are instantiated per asset under the standard instantiation rules. Concept descriptions reuse IEC CDD or ECLASS definitions where a matching property exists, and a local concept description is created only where none does. Because both submodels are added and never substituted, a client reading the reactive AAS through the canonical API is unaffected by their presence. We now state that interoperability of the active layer across vendors would call for these two submodels to be standardized, which this work does not claim.

This change can be found on pp. 6–7, Section 2.4, l. 165–192, with Table 1 on p. 7; the corrected sentence in Section 2.2 is on p. 4, l. 133–138.

Note on table numbering. Three tables are new — the submodel templates (Table 1), the model-selection trajectory (Table 2), the case distribution of the balanced set (Table 3) and the five-model comparison (Table 5) — so the tables of the submitted version are renumbered. The mapping is: infrastructure Table 4; token and cost Table 6; operational metrics Table 7; resources Table 8; service timings Table 9; allocation baseline Table 10; and the new positioning table against related work Table 11.

Comments 6: How would the presented solution compare to a comparative experiment with a monolithic architecture or another proactive architecture?

Response 6: 

We thank the reviewer, and we agree that such a comparison would strengthen the work. As the reviewer notes at the opening of the report, the present study is a feasibility study, and a controlled comparison against a monolithic implementation calls for building and instrumenting a second complete system on the same cell. That is beyond the scope of this submission, and we now say so in the manuscript instead of leaving the absence unexplained.

We have done three things. The qualitative comparison requested in Comments 4 is now Table 9. The limitations section states plainly that the comparison was not made. And the design of the experiment is specified, so that it is a defined piece of future work and not a gesture: the same product variants and the same CFP sequence executed against an AAS server with the decision logic embedded, comparing the time to introduce a variant, the interruption to reactive-layer consumers during an update of decision logic, and the negotiation latency. The conclusions list it among the items future work should carry out.

This change can be found on p. 25, Section 4, l. 672–681, and pp. 25–26, Section 5, l. 703–710.

Comments 7: Clarify the LLM dataset and the process of establishing the reference truth?

Response 7: 

We thank the reviewer. This point was raised independently by all three reviewers, and it led us to replace the evaluation set, not only to describe it.

The manuscript now reports two campaigns, which the submitted version conflated. The timing and cost campaign keeps the 145-case suite that closed the model-selection trajectory and characterises the service on three infrastructures. The decision-quality campaign uses a new set of 454 cases, balanced at 227 positive and 227 negative, each executed five times, giving 2270 evaluations. All decision-quality figures now come from the balanced set alone.

The set is constructed, not sampled. Each case is built by instantiating a requester requirement together with a provider capability declaration whose compatibility follows from the design of the case, so the expected verdict is fixed before the model is invoked. This establishes the reference label without post-hoc annotation: no expert assessment was applied after the fact, and no deterministic reference implementation generated the labels. Our response to Comments 8 explains why the latter was not an option.

The cases are organised in four groups, one per failure mode the algorithm has to survive, and each group is balanced:

Group	Positive	Negative	Total
G1 — Semantic incompatibility between capabilities	51	51	102
G2 — Insufficient inferential evidence	55	55	110
G3 — Limiting properties and parameterization	53	53	106
G4 — Invalid or inconsistent data	68	68	136
Total	227	227	454

We also correct an important ambiguity in the submitted version: the reported executions are not independent cases. Unique cases and executions are now reported separately throughout, since the repetitions are not independent samples.

Two consequences of this change do not favour the paper, and we report them plainly. On the balanced set the F1 of the deployed model is 89.6%, not the 92.0% obtained on the selection suite, and the false-positive rate is 10.8%, not 2.1%. Section 3.3 states why: the selection suite was unbalanced at 21% positive cases and was assembled to discriminate between candidate configurations, whereas the balanced set was assembled to find the limits of the selected one. The lower figures are the ones we now quote for the algorithm, in the abstract and in the conclusions, and the limitations section states the deployment condition that follows from a 10.8% false-positive rate.

Balancing the set also removes the defence the submitted version needed: a classifier that always answered "not capable" now scores 50%, not 79.3%, so accuracy is interpretable alongside F1 and the two agree (89.56% and 89.60%).

The same 454 cases were run over five open-weight reasoning models so that the reported behaviour is not a property of one model (Table 5, and our response to Comments 10 of Reviewer 2).

The system prompt is described in Section 2.9 by its five parts (role, context, matching rules, task, response schema). The complete prompt and the case set are available from the corresponding author, as stated in the Data Availability Statement.

This change can be found on p. 13, Section 2.10, l. 288–317, with Table 3 on p. 13, and pp. 17–19, Section 3.3, l. 459–498.

Comments 8: Compare the presented model with a deterministic constraint validator.

Response 8: 

We thank the reviewer for this suggestion, which we had in fact investigated during development but had not reported. We have added the result.

The decision core was augmented with four deterministic tools exposed as function calls — literal string comparison, interval containment, greater-than and less-than — which are precisely the primitives of a rule-based constraint validator. Contrary to our expectation, performance degraded. The result is reported in Table 2 and in the findings that accompany it: accuracy fell to 46.50% and structural conformity fell from 99.54% to 92.50%, the only configuration in the trajectory that lost structural conformity. The degradation came from failure modes introduced by tool invocation, including malformed tool arguments and loss of the required output schema, which outweighed the arithmetic the tools removed.

We state explicitly, in the limitations, that this compares a model with and without deterministic assistance and is not the comparison the reviewer asked for. A standalone rule-based checker was not run as a baseline, and we say why it would not settle the question on its own: it resolves the cases that turn on numeric bounds and does not resolve those that turn on semantic interpretation of heterogeneous submodel structures, which are the cases the service exists to handle. A hybrid pipeline that routes each case to the mechanism suited to it is stated as the next step, and the balanced campaign now supplies the measurement that would justify its design: semantic incompatibility and limiting properties are resolved above 97% by the deployed model, while the cases that turn on insufficient evidence stay below 75% for every model tested. Those are the cases a deterministic guard or an explicit abstention would have to absorb.

This change can be found on p. 12, Section 2.9, Table 2 and l. 253–262, and p. 25, Section 4, l. 659–671.

Comments 9: What features of the presented model represent a unique approach in the field under study?

Response 9: 

This concern overlaps with the novelty objection raised by Reviewer 2, and we have addressed both together. The manuscript now names three properties, states them in the conclusions where a reader looks for what is new, and positions each one against the related work in Table 9:

1. The type-2 to type-3 upgrade is additive. Existing submodels keep their structure and their consumers; the upgrade inserts only the pair of contract submodels and the services that read them, at the cost of one restart of the reactive part on the provider side, the requester side being updated through the standardized AAS API with no restart at all.
2. After that upgrade, the active layer is redeployed, replaced or rolled back with no restart of the reactive layer. Decision logic hosted inside an AAS server cannot be changed without restarting that server, and every consumer of that server pays for the change.
3. The boundary is declared in the AAS metamodel itself, as the ActiveSteps and ActiveSkills submodel templates, which makes it a modelling artefact instead of an ad hoc integration.

We also state what is not distinctive, since claiming too much was part of the problem: proactive and type-3 behaviour is provided by several of the cited families, capability–skill–service work supplies the semantic matching layer, and separating decision logic from asset data is ordinary service-oriented design for which no contribution is claimed. And we name the dimension on which the proposal does not score well, namely that the two templates are not IDTA-standardized.

This change can be found on pp. 23–24, Section 4, l. 602–625, with Table 11 on p. 24, and pp. 25–26, Section 5, l. 689–698.

Comments 10: Why do the component shares in Table 2 sum to 77.1% (42 + 8.4 + 19 + 1.4 + 6.3), and the "Total" rows sum to 100%?

Response 10: 

We thank the reviewer for catching this. The reviewer is correct that the column does not sum, and we have identified the exact cause.

The column reports a share of cost, not a share of tokens; input and output tokens are priced differently. The three input rows and the two subtotal rows were computed correctly against the provider price list. The two output rows were mistakenly priced at the input rate, understating them by a factor of four. With all five rows given unit weight, the sum becomes 7,694 / 10,004 = 76.9%, which is the 77.1% the reviewer observed.

The revised table separates the two quantities that the original conflated, and reports both. A Share of Tokens column now shows where the tokens are spent, and the corrected Share of Cost column shows where the cost is incurred. Shares are given to two decimal places, and the price list is stated in the table caption so that the computation can be reproduced:

Category	Tokens	Share of tokens	Share of cost
Provider submodel	4187	54.42%	41.85%
System prompt	841	10.93%	8.41%
Requester submodel	1896	24.64%	18.95%
Generated answer	138	1.79%	5.52%
Reasoning output	632	8.21%	25.27%
Total input	6924	89.99%	69.21%
Total output	770	10.01%	30.79%
Total	7694	100.00%	100.00%

The 54% the reviewer computed is now visible as the token share of the provider submodel, alongside its 41.85% cost share, so the two readings no longer conflict.

This correction changes a finding. Output carries 30.79% of the cost while accounting for 10.01% of the tokens, and the reasoning trace alone accounts for 25.27%, second only to the provider submodel. The submitted version stated that "the generated output represented a smaller fraction of the total processing cost", which was wrong. Section 3.3 has been rewritten: two independent levers act on economic viability, payload compaction on the input side and control of the reasoning effort on the output side.

This change can be found on p. 19, Table 6, and p. 19, Section 3.4, l. 500–508.

Comments 11: Section 6 "Patents" is empty?

Response 11: 

Thank you. The section was an unused optional heading from the template and has been removed from the revised manuscript.

Please see the attachment for teh revised version.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

The authors of the paper chose a relevant topic, and described a practically applicable architecture "for separating the reactive AAS layer from an independently deployable active layer"*. The overall concept is understandable, and the robotic screwdriving demonstrator presented in narrative and in VERY NICE figures gives the work a nice engineering/applicability context. The requester–provider interaction, deployment pipeline with active skill/steps submodels are presented in a coherent way.

* I understand the above-mentioned layer separation as "data stays the same, while the smart functions can be used/changed separately". This does not constitute novelty - this may describe the majority of existing systems - so the readers will possibly have to dig deeper to find innovation.

Unfortunatelly, the manuscript is not ready yet to be published. There are at least three aspects of the manuscript that need authors' attention.

1. The figures. They are nice and informative, but
- there are many words with the red underline, which means that the word waas not recognized by MsWord dictionary (disable language before screenshot). It really disrupts "reading" the diagrams.
- Figure 2,3 is too small, it could be wide figure (use \begin{figure*} instead of \begin{figure}).
- Figure 5: I had to search online to see what is "Minipa", looking at the image I thought it is a part of this arm. Move this label or use it in other way.
- Figure 7: -is in Spanish??
- Figure 8a,8b - should be the same size if presented in grid

2. Language. //style
I honestly resect that you were honest to disclose the use of AI for "language refinement and manuscript consolidation", and are "fully responsible" for the work. This is the proper approach. However, despite your declaration, I would recommend to alter the style of the text, at least in the most basic parts like abstract, beginnings of chapters, conclusions. Why? Becouse a lot of researchers do not believe in "declarations" and/or "responsibility". They start reading, they "smell ChatGPT", they stop reading and never cite your work. I believe you do have interesting research to present (the figures alone are convincing enough for me) but if you want to increase impact/quality, try to stay away from
- x requires y
- x while y
- x remain y
- x, y and z
- x rather than y
- x, viable y
- x indicating y
- "and provides a basis for"
- m-hyphens (as in "leaving the reactive layer—and its certification trail—untouched")

3. Language. //"depth"
Some parts of the manuscript use a broad, "promotional"/marketing style. Some claims are repetitive. The central contribution is restated several times, while useful technical details (useful for trying to replicate the research) remain missing. The authors should reduce generic claims and clearly separate measured findings from expected benefits. Such "situation" may occur if the LLM used during language refinement has too much control over style. But this remains the responsibility of the authors to control the "freedom of speech" of the LLM-resulted sentences. Therefore, the authors may want to revise the manuscript so that every conclusion is directly supported by the reported method and data.

4. Numbers.
The most important issue is the consistency of the reported numbers. In Table 2, the token counts do not match the stated percentages. 4187 tokens out of 7694 correspond to +-54%, not 42%;  the reported total input and output percentages also do not match the listed token totals.  The percentages do not add up to 100%.  The cost calculation is unclear - a reported total cost of USD 0.51 of 725 evaluations is roughly about 0.0007 $ per evaluation, not 0.0004.  Such "simple to check" inconsistencies should be corrected and avoided (and supported by transparent formulas and pricing), so that the readers would not doubt your other results also.

4. Methodology.
The LLM-based capability evaluation may also benefit from mor detailed description. It would be nice if the authors explain how the 725 test cases were created, how ground truth was established, whether the cases were unique, what prompts and model configurations were used, and how any ambiguous or invalid outputs were handled.
Some claims seem to be much broader than the presented evidence. Successful operation of (one) demonstrator does not define/establish general interoperability or scalability. The reported 38% throughput gain is based on an offline estimated baseline, is it? So it should be presented/declared as a preliminary demonstrator performance not a definite production improvement.

Comments for author File: Comments.pdf

Author Response

Comments 1: I understand the above-mentioned layer separation as "data stays the same, while the smart functions can be used/changed separately". This does not constitute novelty - this may describe the majority of existing systems - so the readers will possibly have to dig deeper to find innovation.

Response 1: 

We thank the reviewer for stating this so directly, and we accept the criticism. At the level of abstraction at which the manuscript was written, the separation we described is conventional software architecture, and the manuscript did not defend the distinction. The revised Section 4 now says so explicitly: separating decision logic from asset data is, on its own, ordinary service-oriented design, and no contribution is claimed for it.

What we do claim is a combination of three properties that the related work addresses in isolation, and Table 9 shows where each family stands on them:

1. The type-2 to type-3 upgrade is additive. Existing submodels keep their structure and their consumers; the upgrade inserts only the pair of contract submodels and the services that read them. It costs one restart of the reactive part on the provider side, whose AAS loads its submodel set at start-up, while the requester side is updated through the BaSyx API with no restart. We now state this rather than leave it implicit.
2. After that upgrade, the active layer is redeployed, replaced or rolled back with no restart of the reactive layer. This is the property that a conventional split does not provide: decision logic hosted inside an AAS server cannot be changed without restarting that server, and every consumer of that server pays for the change.
3. The boundary is declared in the AAS metamodel itself, as the ActiveSteps and ActiveSkills submodel templates, which makes it a modelling artefact instead of an ad hoc integration. Without ActiveSkills, the active state machine has to know which submodels implement each function, so replacing a capability service means changing the active layer. Without ActiveSteps, orchestration lives in service code and every product variant becomes a code deployment.

Section 2.1 defines what preservation means in each of its three senses, since the submitted version used "unchanged" and "untouched" to carry all of them at once, and Section 3.1 reports what the demonstrator showed against each.

We have also stated the dimension on which the proposal does not score well: the two templates are not IDTA-standardized, so the contract is portable within an implementation and not across vendors.

This change can be found on pp. 23–24, Section 4, l. 602–625, with Table 11 on p. 24; pp. 2–3, Section 2.1; and pp. 15–16, Section 3.1.

Comments 2: The figures. They are nice and informative, but there are many words with the red underline, which means that the word was not recognized by MsWord dictionary (disable language before screenshot). It really disrupts "reading" the diagrams.

Response 2: 

Thank you for this observation, and we apologize for the oversight. The affected diagrams have been re-exported with proofing marks disabled. Figure 6 (p. 10) and Figure 7 (p. 11) no longer contain spell-checker underlines.

Comments 3: Figure 2,3 is too small, it could be wide figure (use \begin{figure*} instead of \begin{figure}).

Response 3:

We agree that both figures were illegible at the submitted size. In the single-column MDPI layout, figure* has no effect; the equivalent mechanism is the adjustwidth environment provided by the journal class, which extends the figure into the wide outer margin. Both figures now use \begin{adjustwidth}{-\extralength}{0cm}, increasing the usable width from 13.86 cm to 18.47 cm, a 33% gain.

This change can be found on p. 6, Figure 2, and p. 8, Figure 3.

Comments 4: Figure 5: I had to search online to see what is "Minipa", looking at the image I thought it is a part of this arm. Move this label or use it in other way.

Response 4: 

Thank you — the label was ambiguous, and it was also inconsistent with the other callouts in the same figure, which are functional rather than commercial. The callout now reads "Collaborative robot", matching "Screwing Jig" and "Screw Dispenser", and the commercial identification has been moved to the caption in the format used for equipment:

"The robot is a CR3 collaborative arm (Dobot CR3, Shenzhen Yuejiang Technology Co., Ltd., Shenzhen, China; supplied in Brazil by Minipa Robotics), with 3 kg rated payload and 620 mm reach."

This change can be found on p. 9, Figure 5 and its caption.

Comments 5: Figure 7: -is in Spanish??

Response 5: 

Thank you for catching this. The figure was in Portuguese, and it was the wrong figure: its caption described the provider AAS view while the image showed the generic layer diagram. The cause was a filename collision (Provider.png and provider.png resolving to the same file on a case-insensitive filesystem), so the intended English figure was never embedded. The correct figure is now included and matches its caption.

This change can be found on p. 11, Figure 7.

Comments 6: Figure 8a,8b - should be the same size if presented in grid

Response 6:

We agree. Both panels now occupy identical 6.0 × 5.4 cm bounding boxes with equal minipage widths, and their titles are aligned at the same height. Panel labels (a) and (b) have been added, and the caption now describes each panel separately.

This change can be found on p. 18, Figure 8.

Comments 7: Language. //style — [...] I would recommend to alter the style of the text, at least in the most basic parts like abstract, beginnings of chapters, conclusions. [...] try to stay away from "x requires y", "x while y", "x remain y", "x, y and z", "x rather than y", "x, viable y", "x indicating y", "and provides a basis for", m-hyphens.

Response 7:  PARTIALLY APPLIED — abstract done, section openings and conclusions pending

We appreciate both the candour and the practical reasoning behind this comment. We checked the manuscript against the constructions the reviewer listed and confirmed that they were present at high frequency, including the two quoted verbatim. Em dashes used as parenthetical connectors have been removed throughout; none remain.

The abstract has been rewritten and now contains none of the listed constructions. It has also been reduced from 273 to 199 words, within the journal limit.

Working on this comment showed us that the style was not only a matter of perception. Several of the constructions were carrying claims that turned out to be imprecise, and rewriting them exposed the imprecision. The previous abstract asserted that the architecture "was validated to verify interoperability, responsiveness, and repeatability" and that results "show stable end-to-end negotiation, viable latency, and preservation of reactive AAS assets", without reporting a single measured quantity. The revised abstract reports what was measured, with its denominators: 102 of 104 calls for proposal received a proposal at a median of 4 s; median requester activation was 8 s over 100 activations; capability checking over 454 balanced cases reached an F1 of 89.6% with a 10.8% false-positive rate, at USD 7.0×10⁻⁴ per evaluation. It also states what was not tested, in the final sentence.

Two claims were dropped rather than rephrased, because the evidence does not support them: the description of requester instances as "low-footprint" containers, which is addressed in our response to Reviewer 3, Comments 3; and the claim that a single demonstrator assessed interoperability, which is addressed in our response to Comments 11 below.

This change can be found on p. 1, Abstract. The rewriting of the section openings and the conclusions is in progress and will be included in the revised submission.

Comments 8: Language. //"depth" — Some parts of the manuscript use a broad, "promotional"/marketing style. Some claims are repetitive. The central contribution is restated several times, while useful technical details remain missing. The authors should reduce generic claims and clearly separate measured findings from expected benefits.

Response 8:

We accept this. We have audited every architectural claim and classified it as measured, argued, or expected. Claims of interoperability, scalability, repeatability and low footprint that were not backed by a reported measurement have either been bound to a measurement, restated as design objectives, or removed. The restatements of the central contribution have been consolidated into a single statement in the Introduction and one in the Discussion.

In exchange, we have added the technical detail needed for replication: the model selection protocol (Reviewer 1, Comments 1), the formal submodel definitions (Reviewer 1, Comments 5), the evaluation protocol and dataset (Reviewer 1, Comments 7), and the cost-optimization results described in Comments 9 below.

This change can be found throughout the revised manuscript.

Comments 9: Numbers. The most important issue is the consistency of the reported numbers. In Table 2, the token counts do not match the stated percentages. 4187 tokens out of 7694 correspond to +-54%, not 42%; the reported total input and output percentages also do not match the listed token totals. The percentages do not add up to 100%. The cost calculation is unclear - a reported total cost of USD 0.51 of 725 evaluations is roughly about 0.0007 $ per evaluation, not 0.0004. Such "simple to check" inconsistencies should be corrected and avoided (and supported by transparent formulas and pricing), so that the readers would not doubt your other results also.

Response 9:

We thank the reviewer for this scrutiny and we accept the criticism in full. The table did not sum, the cost figure was wrong, and neither was supported by a stated formula.

On the table: the column reported a share of cost, not of tokens, since input and output are priced differently, which is why the 54% the reviewer computed did not match. The reviewer is nonetheless right that the column was inconsistent: the two output rows had been priced at the input rate, understating them fourfold. Table 4 now reports both quantities in separate columns, so the 54% appears explicitly as the token share of the provider submodel alongside its 41.85% cost share, and the price list is stated in the caption. The full diagnosis is in our response to Reviewer 1, Comments 10.

On the cost per evaluation: the reviewer is correct and the value of USD 0.0004 was wrong. The manuscript now states the price list, the formula and both figures. At list price an evaluation of 6924 input and 770 output tokens costs 6924 × 0.075e-6 + 770 × 0.30e-6 = 7.50e-4 USD, so a round of 725 evaluations was budgeted at USD 0.544. The round actually billed USD 0.51, because part of the input context was served from cache at the reduced rate of USD 0.037 per million tokens, and the measured cost per evaluation is therefore 0.51/725 = 7.0e-4 USD — the value the reviewer computed. The submitted version reported the USD 0.51 total without the USD 0.544 estimate it was being compared against, which is what made the sentence "below the initial planning estimate" unverifiable.

The audit this comment prompted turned up four further problems, all of which we have corrected:

• The sample size was overstated. The 725 figure counted executions, not independent cases: it was 145 unique cases executed with five repetitions. Unique cases and executions are now reported separately throughout, since repetitions are not independent samples. That suite has since been superseded for decision quality by a balanced set of 454 cases and 2270 executions (see our response to Reviewer 1, Comments 7); the 145-case suite now supports only the timing and cost figures, where it is identified as such. The count of cases run on the rented GPUs was also wrong, stated as 125 where the confusion matrices sum to 145.
• The determinism claim was false. The submitted version stated that inference used "temperature set to zero and a fixed seed". A fixed seed was used only in early development and was deliberately abandoned, because the protocol measures how often a model succeeds across repetitions of the same case. The sentence has been removed and the stochastic protocol is described.
• The infrastructure table mixed measured and estimated values without distinguishing them. It has been rebuilt. Client-observed times are now given with their standard deviations, server-side times are separated from them, and quantities that were not recorded are marked as such rather than left blank. We also state the measurement caveat that the submitted version omitted: the rented GPUs were on a different continent from the client, so their client-observed means of 5.54 s and 4.83 s are dominated by network transit and are not comparable with the serverless figure.
• One reported figure was not supported. A generation throughput of 1500 tokens/s had been reported for the RTX PRO 6000 WS. Our own records show that the server-side logs for that configuration were not captured, so no throughput could be derived. The figure has been removed and the cell marked "not captured".

We note that none of these corrections affects the conclusion. The capability check runs inside a negotiation whose end-to-end cycle takes 44 to 82 s, so the decision service is not the limiting element on any of the three infrastructures, and we now say so explicitly.

This change can be found on p. 17, Table 4, and pp. 16–17, Section 3.2, l. 430–457; p. 19, Table 6, and p. 19, Section 3.4, l. 500–508; and pp. 12–14, Section 2.10, l. 278–336.

Comments 10: Methodology. The LLM-based capability evaluation may also benefit from more detailed description. It would be nice if the authors explain how the 725 test cases were created, how ground truth was established, whether the cases were unique, what prompts and model configurations were used, and how any ambiguous or invalid outputs were handled.

Response 10: 

We thank the reviewer. Each of the five points is now addressed in the revised evaluation protocol:

• How the cases were created and how ground truth was established — see our response to Reviewer 1, Comments 7. The evaluation set has been replaced by a balanced set of 454 constructed cases, 227 positive and 227 negative, organised in four failure-mode groups: semantic incompatibility between capabilities, insufficient inferential evidence, limiting properties and parameterization, and invalid or inconsistent data. Each case carries a verdict fixed at construction.
• Whether the cases were unique — they are not, and the submitted version did not make this clear. The 454 unique cases are each executed five times, giving 2270 evaluations. Unique cases and executions are now reported separately.
• Prompts — the prompt is a five-part structure (role, context, matching rules, task, response schema), now stated in Section 2.9. The matching-rules block carries the strictness rules applied to submodel identity, types and units, category semantics, missing data, and range validity. The complete prompt is available from the corresponding author under the Data Availability Statement.
• Model configuration — the model, the reasoning-effort setting and the sampling protocol are stated in Sections 2.9 and 2.10. Inference is not deterministic: the generator seed is left free and each case is executed five times, so the reported quality reflects the variability of the model under repetition.
• Invalid or ambiguous outputs — these are measured rather than discarded. We report structural conformity, CE = valid inferences / total inferences, where an inference is valid if it returns a schema-conformant JSON verdict. Non-conformant outputs are counted through CE and excluded from the F1 computation, so that classification quality is measured only over verdicts the provider state machine could consume. On the balanced set every one of the five models evaluated returned a conformant verdict in every execution, so CE was 100% throughout.

Acting on this comment did more than document the protocol. Because the balanced set is harder, the reported decision quality fell: F1 from 92.0% to 89.6% and the false-positive rate from 2.1% to 10.8%. We report the lower figures, and Section 3.3 explains the difference between the two suites. On a balanced set accuracy is also interpretable again, and it agrees with F1 (89.56% against 89.60%), instead of diverging by nearly five points as it did on the unbalanced suite.

We further used the same 454 cases to compare five open-weight reasoning models (Table 5), which addresses the reviewer's concern about model configuration from the other side: the behaviour is a property of the task and not of one model. Three findings are reported. Model size does not order the results, since GPT-OSS-120B leads three of the four groups yet loses the aggregate to the 20B variant. The length of the reasoning trace is inversely related to accuracy over the observed range, from 544 tokens at 89.56% to 3599 tokens at 70.66%. And insufficient inferential evidence defeats every model tested, none exceeding 74.73% on that group, which locates the failure mode precisely: the difficulty is not semantic matching but recognising that a declaration does not carry enough information to decide.

This change can be found on pp. 11–12, Section 2.9, l. 243–276; pp. 12–14, Section 2.10, l. 278–336, with Table 3 on p. 13; and pp. 17–19, Section 3.3, l. 459–498, with Table 5 on p. 18.

Comments 11: Some claims seem to be much broader than the presented evidence. Successful operation of (one) demonstrator does not define/establish general interoperability or scalability. The reported 38% throughput gain is based on an offline estimated baseline, is it? So it should be presented/declared as a preliminary demonstrator performance not a definite production improvement.

Response 11: 

We agree on both points.

On the throughput gain: the reviewer is correct that the baseline is an offline allocation estimate. The manuscript stated this in the body but not where a reader meets the number. The caption of the allocation table now carries the qualification as well, stating that the makespan, the throughput and the 38% relative gain are offline estimates of the allocation policy and not a measured production improvement, and that the baseline does not re-simulate transport contention, queueing or cell-level disturbances.

On the broader claims: interoperability was asserted beyond what one demonstrator establishes. Section 3.1 now reports the observation and stops there — the reactive side was exposed by pure OPC UA resources and by AAS-oriented stacks with no change to the requester logic — and states explicitly that this was observed for the resources of this demonstrator and is not a general interoperability result. The generalised claim has been removed from all three places where it appeared: the conclusions, which stated that the architecture "interoperates with heterogeneous reactive implementations"; the opening of the discussion, which described proactive digital twins as "interoperable decision-capable entities"; and the abstract, whose closing sentence now states that scalability and cross-vendor interoperability were untested. Extending the validation to multi-cell lines with explicit scalability experiments is stated as future work.

Three related corrections that this comment prompted are described in our response to Comments 9: the validation setting, which the submitted version described inconsistently across four passages; the robot count, stated in the singular where the results report allocation across three; and a reference to vision-assisted positioning, which the demonstrator does not have.

This change can be found on p. 16, Section 3.1, l. 424–429; p. 22, Table 10 caption; p. 1, Abstract; and pp. 25–26, Section 5.

This comment also prompted a related correction. The submitted version described the validation setting inconsistently: the abstract stated the demonstrator was built at the university and is not a live production line, while the Introduction and Section 2.6 described an industrial cell operating in the Manaus industrial district. The passages now agree, and the demonstrator is described as it is — an industrial-grade cell built at the university, reproducing a station of the type deployed in that district, not part of a live line. We also corrected the robot count, which was stated in the singular while the results report allocation across three robots, and removed a reference to vision-assisted positioning, which the demonstrator does not have.

That correction can be found on p. 2, Section 1, l. 46–52 (Introduction) and pp. 8–9, Section 2.6, l. 212–223.

Please see the attachment for the revised version.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

1. Table 4 would benefit from additional clarification. In particular, the reported network usage per CFP (0.0/0.0 kB, mean/max) is difficult to reconcile with the communication architecture described in Section 2.5, since MQTT-based negotiation messages are actively exchanged within these sampled windows. The manuscript should clarify the measurement methodology, monitored interfaces, sampling approach and any assumptions or exclusions applied during data collection.
2. The quantitative evaluation reports several different sample sizes across Tables 3-5 (e.g. 175 capability checks, 160 feasibility checks, 102 CFPs with proposal), but the relationship between these datasets is not fully explained. A brief description or a simple flow diagram, highlighting how these sample counts relate to one another would improve the transparency and reproducibility of the evaluation and help readers to comprehend the reported metrics.
3. The abstract describes requester instances as “low-footprint Docker container”. However, the manuscript does not define what “low footprint” refers to or provide quantitative evidence supporting this characterization. Since Section 3.4 notes that the storage-per-package metric (STOpkg) was not collected, it would be beneficial either to clarify the meaning of “low-footprint” (e.g. storage, memory) and support it with appropriate measurements, or to soften the wording so that it is presented as a design objective rather than a demonstrated property.
4. It would be beneficial to describe how the ground-truth labels for the 725 capability-checking cases were established, since these labels underpin the reported confusion matrix and false-positive rate. A brief description of the labeling procedure (e.g. expert assessment, deterministic reference implementation) would improve the reproducibility and credibility of the results.

Author Response

Comments 1: Table 4 would benefit from additional clarification. In particular, the reported network usage per CFP (0.0/0.0 kB, mean/max) is difficult to reconcile with the communication architecture described in Section 2.5, since MQTT-based negotiation messages are actively exchanged within these sampled windows. The manuscript should clarify the measurement methodology, monitored interfaces, sampling approach and any assumptions or exclusions applied during data collection.

Response 1: 

We thank the reviewer, and we agree without reservation: the value cannot be correct as printed. A maximum of zero is impossible while the negotiation itself is carried over MQTT inside the sampled windows, so the traffic exists by construction. The figure described the instrument and not the system.

The row has been removed and the manuscript now says why, rather than leaving a reader to reconcile it: the per-container counter deltas rounded to zero at the resolution recorded, and the measurement did not isolate the interfaces that actually carry the negotiation. Quantifying negotiation traffic from message counts and payload sizes is stated as a dedicated measurement still to be made.

The measurement methodology for the remaining resource metrics is now stated, which addresses the four points the reviewer raised. Resource figures are point samples of the Docker statistics of the active-layer containers, taken at a fixed period and attributed to the CFP window they fall in. Two consequences are now visible in the table instead of being smoothed over: a CFP whose window is shorter than the sampling period contributes no sample, which is why the CPU and memory figures rest on 83 and 87 of the 104 windows; and because each sample is a point reading rather than an integral, the reported maxima are the highest instantaneous values observed and not peaks guaranteed to have been captured.

This change can be found on p. 20, Section 3.5, l. 529–541, and p. 21, Table 8.

Comments 2: The quantitative evaluation reports several different sample sizes across Tables 3-5 (e.g. 175 capability checks, 160 feasibility checks, 102 CFPs with proposal), but the relationship between these datasets is not fully explained. A brief description or a simple flow diagram, highlighting how these sample counts relate to one another would improve the transparency and reproducibility of the evaluation and help readers to comprehend the reported metrics.

Response 2: 

We thank the reviewer for this suggestion, which we have adopted. Figure 9 now traces the negotiation stages and the count each one produces, with the dashed branches accounting for the differences: 104 CFPs emitted, of which 2 received no proposal; 175 provider responses, each one a capability check, of which 15 refused; 160 proposals, each one a feasibility check, of which 60 were rejected; 100 acceptances and 100 completed services.

Two counts needed an explicit explanation, and the manuscript now gives it. The 175 provider responses average 1.68 per CFP rather than the three that a three-robot cell might suggest, because a provider executing a contracted service does not bid. A CFP issued while all three robots are free draws three proposals; the next, issued while the winner is still working, draws two; the one after that draws one. Responses per CFP fall as robots become occupied and recover as they complete. The 60 rejected proposals are the losing bids of CFPs that received more than one, since each CFP awards a single provider.

We have also stated the measurement window explicitly. All counts and latencies are computed over the automatic-simulation interval; the dashboard additionally holds earlier manual tests, which the window excludes, so totals read directly from the raw event log are larger than those reported. The rejected proposals, which the submitted version omitted entirely, are now reported.

This change can be found on pp. 19–20, Section 3.5, l. 510–528, with Figure 9 on p. 20.

Comments 3: The abstract describes requester instances as "low-footprint Docker container". However, the manuscript does not define what "low footprint" refers to or provide quantitative evidence supporting this characterization. Since Section 3.4 notes that the storage-per-package metric (STOpkg) was not collected, it would be beneficial either to clarify the meaning of "low-footprint" (e.g. storage, memory) and support it with appropriate measurements, or to soften the wording so that it is presented as a design objective rather than a demonstrated property.

Response 3: 

The reviewer is right, and we thank them for the precise framing. The term was undefined, the storage-per-package metric was acknowledged as uncollected, and the only related measurement reported was memory per CFP, which is not a container footprint.

Of the two remedies the reviewer offered, we took the second and went further: rather than soften the wording, we removed the claim. The abstract no longer describes requester instances as low-footprint, and the term appears nowhere in the revised manuscript. We prefer to drop an unsupported characterisation than to restate it as an objective, since the paper does not evaluate it either way. Section 3.4 continues to list storage per active package among the metrics that additional instrumentation would be needed to collect.

This change can be found on p. 1, Abstract.

Comments 4: It would be beneficial to describe how the ground-truth labels for the 725 capability-checking cases were established, since these labels underpin the reported confusion matrix and false-positive rate. A brief description of the labeling procedure (e.g. expert assessment, deterministic reference implementation) would improve the reproducibility and credibility of the results.

Response 4: 

We thank the reviewer, and we note that this concern was shared by both other reviewers. Section 2.10 now describes the labelling procedure.

The labels are established by construction rather than by annotation. Each case is built by instantiating a requester requirement together with a provider capability declaration whose compatibility follows from the design of the case, so the expected verdict is fixed before the model is invoked. Neither of the two procedures the reviewer offered as examples was used: there was no post-hoc expert assessment, and no deterministic reference implementation generated the labels. We also say why the latter was not an option — a rule-based checker resolves the cases that turn on numeric bounds, but not those that turn on semantic interpretation of heterogeneous submodel structures, which are the cases the service exists to handle.

The cases derive from the failure modes the algorithm has to survive: incompatibility between the capability requested and the one offered; requirements the provider declaration carries insufficient evidence to satisfy; numeric bounds the request violates; and inconsistent or invalid data such as mismatched types and units.

We have also replaced the evaluation set, which bears directly on how the confusion matrix should be read. Decision quality is now reported over 454 constructed cases, balanced at 227 positive and 227 negative, executed five times each, so the matrix and the false-positive rate count 2270 executions and not independent samples. This is stated in both Section 2.10 and Section 3.3. On this harder, balanced set the false-positive rate is 10.8% rather than the 2.1% of the submitted version, and we report the higher figure together with the deployment condition it implies.

This change can be found on p. 13, Section 2.10, l. 297–317, and pp. 17–19, Section 3.3, l. 459–498.

Please see the attachment for the revised version.

Author Response File: Author Response.pdf