Pith. sign in

REVIEW 4 major objections 4 minor 98 references

White paper: A perspective on civilian-to-defence research transfer to SDD

T0 review · 4 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read This white paper argues that the lifecycle paradox — defence hardware procured over decades while the software on it must change within days — is the central problem Software-Defined Defence must solve, and that a continuous DevOps-style…

desk verdict Useful and honest SDD roadmap; the transferability premise is its biggest open question, but the paper names that question better than most position papers. read the letter →

arxiv 2608.09349 v1 pith:2BNGLQ56 submitted 2026-08-10 cs.SE cs.NI

Rute C. Sofia , Daniel Mendez , Simon Barner , Hao Shen , Julian Woermann , Andrea Stocco , Axel von Arnim , Holger Pfeifer
show 1 more author
Alexander Pretschner
This is my paper · ORCID
classification cs.SEcs.NI
keywords Software-DefinedDefencelifecycleparadoxcontinuousengineeringloopmodel-basedsystemssimulation-basedtestingtacticalconnectivitylow-poweredgeexecutioncivilian-to-defencetechnologytransfer
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

This white paper argues that the central engineering problem facing Software-Defined Defence is the lifecycle paradox: defence platforms are procured on decade-long timescales while the software and AI models they carry must be updated within days or hours. Its thesis is that a sustainable solution already exists in civilian engineering practice, provided it is reorganised into a continuous DevOps-style loop that front-loads design and verification, carries them into contested operation, and runs compliance and assurance continuously beneath both. The paper assesses four core capabilities — model-based systems engineering, simulation-based testing, tactical connectivity, and low-power edge execution — and claims each is already proven in automotive, manufacturing, space, or energy settings, with the remaining work being redirection toward adversarial conditions rather than invention from scratch. If the thesis holds, defence procurement and certification can move from one-shot delivery to incremental, evidence-based updates, and the same technology base applies to civilian critical-infrastructure resilience.

What carries the argument

The machinery that carries the argument is the continuous DevOps-style SDD loop together with its central transfer device, the claim that the search mechanism of simulation-based testing is domain-agnostic. The loop has four core stages — model-based systems engineering for design and verification front-loading; simulation-based testing, including automated search-based scenario discovery; tactical and resilient connectivity spanning deterministic (time-sensitive networking), opportunistic, and delay-tolerant (bundle-protocol and named-data networking) regimes; and low-power neuromorphic edge execution — with three cross-cutting concerns, continuous cybersecurity compliance, variability and reuse management, and continuous assurance and resilient AI, running beneath all of them. The transfer device is exemplified by an open-source search-based testing framework that explores an operational design space automatically to expose failure modes: redirected from braking-distance objectives to jamming, spoofing, or degraded-GPS fitness functions, the same pipeline is claimed to surface adversarial failure modes in simulation before fielding. The lifecycle paradox is the framing object that motivates the loop: it is the mismatched-timescale diagram of a platform whose mechanical baseline lasts decades while its AI models are retrained in hours, and the loop is designed to absorb those divergent rhythms.

What would settle it

Take the paper's open-source search-based testing framework, redirect its fitness objective from braking distance to sensor denial or jamming, and run it against a public perception or navigation model; then expose the same model to physical jamming in a denied, disrupted, intermittent, and limited testbed. If the simulated failure catalogue misses failures the physical run produces, the claim that the search mechanism is domain-agnostic and that only adversarial validation is missing would be falsified; if the catalogues match, the transfer claim survives.

Watch

Extended reading notes

Core claim

On the paper's own terms, the claim is that Software-Defined Defence must be built around a continuous engineering loop rather than a sequential acquisition model. The lifecycle paradox — hardware that lasts decades against software that changes weekly and AI models that change daily — is not a procurement inconvenience but the defining engineering constraint, and it forces three dimensions to be engineered together: software and systems engineering, AI engineering, and connectivity and infrastructure engineering. The paper's constructive claim is that a DevOps-inspired loop can carry a platform from design through contested operation: model-based systems engineering and simulation-based testing front-load verification; tactical connectivity and low-power edge execution carry the design into denied, disrupted, intermittent, and limited conditions; and continuous cybersecurity compliance, continuous assurance, and variability management run beneath both phases. Each of these capabilities, the paper argues, is already validated in civilian and dual-use domains, so the remaining scientific question is not whether the technology is relevant but what must be added, tested, or hardened to make it trustworthy under adversarial conditions — a transfer claim the paper states explicitly for search-based testing, whose search mechanism it describes as domain-agnostic.

Load-bearing premise

The load-bearing premise is that engineering methods validated in civilian and dual-use settings become trustworthy under actively adversarial conditions — jamming, spoofing, and sensor denial — by redirecting test objectives and adding hardening, without a qualitative change in the method itself.

Editorial extensions

If this is right

  • Defence acquisition and certification can shift from one-shot delivery to incremental, evidence-based updates, where a change to one module triggers re-evaluation of only the affected assurance arguments rather than full platform re-certification.
  • A system certified in 2025 could carry AI models trained on 2040 data, because continuous assurance and traceability keep a timestamped evidence record that stays current across patches and retraining runs.
  • Search-based testing redirected at adversarial objectives could produce, in simulation and before fielding, the failure catalogue that jamming, spoofing, and sensor-denial certification currently lack, at a fraction of field-trial cost.
  • Tactical networks that combine deterministic networking with store-carry-forward and in-network caching could keep mission data flowing across deterministic, opportunistic, and delay-tolerant regimes, provided the deterministic-to-delay-tolerant handoff is closed.
  • Neuromorphic, event-driven edge execution could keep a soldier-worn or platform-mounted system learning and adapting without a live backhaul link, which is exactly the condition contested environments impose.

Reading between the lines

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

  • Applied in reverse, the paper's transfer thesis implies that SDD capability work doubles as civilian critical-infrastructure resilience work: an energy or telecoms network under sustained cyber and disinformation pressure faces the same continuous-update-under-adversary problem, so the same loop applies — a direction the paper notes but leaves undeveloped.
  • If the domain-agnostic claim holds, the open adversarial-robustness benchmark the paper proposes for 2027–2029 could become a shared alliance-level certification instrument, letting different nations cite the same failure catalogue instead of re-deriving evidence — a consequence the paper leaves implicit.
  • A testable extension the paper does not run: apply the unmodified search-based testing mechanism to a public perception model with a sensor-denial fitness objective, then compare the simulated failure catalogue with one produced under physical jamming; the size of that simulation-to-reality gap in adversarial conditions is what would decide how far the loop's evidence can be trusted.
  • The paper's own 2030 horizon may be optimistic: the deterministic-to-delay-tolerant handoff is named as unsolved, and the short-term pilot that would close it is scheduled in the same 2026–2027 window as the adversarial testing meant to feed certification — if the handoff resists standardisation, the medium-term certification pipeline stalls.
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.

Referee Report

4 major / 4 minor

Summary. This white paper argues that the central engineering challenge of Software-Defined Defence (SDD) is the 'lifecycle paradox'—the mismatch between decade-long hardware procurement cycles and software and AI that must evolve on a timescale of days—and proposes a continuous DevOps-style engineering loop built from four core capabilities (model-based systems engineering, simulation-based testing, tactical connectivity, low-power edge execution) plus three cross-cutting concerns (cybersecurity compliance, variability management, continuous assurance). For each capability, the paper assesses civil-domain maturity, often using fortiss's own tools and projects as illustrative evidence, assigns TRL levels, identifies open transfer problems, and offers a 2026–2030 roadmap for validation under adversarial and defence-certified conditions. The paper is written as a perspective and a call to action for researchers, industry, policymakers, and defence agencies.

Significance. If the central transfer premise holds, the paper provides a valuable and actionable framing for defence digitalization: it names the lifecycle paradox as the core problem, connects it to concrete engineering capabilities, and offers a time-horizoned roadmap. A notable strength is the paper's candour about open gaps—most prominently the TSN-to-DTN handoff and the lack of adversarial validation for search-based testing—which makes the assessment more credible than typical white papers. The paper also points to open-source tools and standards (AutoFOCUS3, OpenSBT, IETF DetNet/RAW), which are checkable. However, the evidence base is largely self-referential: the maturity assessment for each capability rests on fortiss's own tools and self-assigned TRL levels, and the sustainability claim in the Executive Summary is broader than the evidence supports. Disagreement with consensus is not at issue; rather, the paper's central claim would be strengthened by tempering its scope or providing independent validation.

major comments (4)
  1. [Executive Summary; Section 4] The claim that the proposed DevOps SDD loop is 'sustainable, considering existing capabilities and methodologies that have been built and proven' in civilian domains is broader than the evidence presented in Section 5. The maturity evidence consists of fortiss's own tools at self-assessed TRL 5-6, none of which has been validated under adversarial or defence-certified conditions, and Section 5.3 explicitly states that the TSN-to-DTN handoff is unsolved. A TRL of 5-6 in benign civilian settings does not by itself establish that the capability will be sustainable when an adversary actively tries to break it. Please soften the sustainability claim to a conditional one, or provide a more detailed maturity assessment with independent evidence and a transparent TRL rubric.
  2. [Section 5.2, Section 6.1] The transfer claim for search-based testing is asserted rather than demonstrated. The paper states that OpenSBT's 'search mechanism itself is domain-agnostic' and that redirecting the fitness objective to jamming or spoofing 'could surface' failure modes. This assumes that adversarial behaviour can be represented as fixed input-space parameters drawn from a stationary distribution. In practice, an adversary observes the system and adapts, so the search space becomes a game rather than a parameter space; the same pipeline may only find failures that the modeler has explicitly parameterized, missing reactive strategies such as state-dependent GPS spoofing or communications jamming. The paper should either provide evidence that search-based testing can cope with adaptive adversaries—for example, a study applying OpenSBT with an adaptive jamming model—or explicitly state this limitation and explain how the roadmap would address it.
  3. [Section 5.3, Section 6.1] The paper admits that the TSN-to-DTN handoff is 'unsolved in both the civilian and defence literature' (Section 5.3), yet the short-term roadmap (Section 6.1) proposes a 2026–2027 pilot that would 'prove the handoff under representative constraints.' This timeline is difficult to reconcile with the acknowledged research gap. Please clarify whether the pilot is intended to solve an open research problem or to demonstrate an existing partial solution, and specify what evidence would constitute success for the pilot.
  4. [Section 5.1-5.5] The TRL values assigned to each capability are self-assessments by the authors, but the paper does not describe the method by which these levels were determined or whether they were reviewed by independent domain experts. Since the paper's central argument depends on the claimed maturity of these capabilities, the TRL assessment should be presented as a provisional self-assessment rather than as an established classification, or a separate validation process should be described.
minor comments (4)
  1. [Section 5.2] The sentence 'Redirected from braking-distance objectives to a UAS navigation or target-identification model, with jamming or spoofing as the fitness objective instead of collision distance, the same pipeline could surface degraded-GPS or adversarial-perturbation failure modes in simulation before fielding' appears verbatim twice in Section 5.2, once in 'Illustrative evidence' and once in 'Maturity and gap.' Remove the duplicate.
  2. [List of Acronyms] The entry for 'SyNAPSESystems of Neuromorphic Adaptive Plastic Scalable Electronics' is malformed; it should read 'SyNAPSE (Systems of Neuromorphic Adaptive Plastic Scalable Electronics).'
  3. [Section 2.5, Figure 2] The text labels 'Mechanical/Structural platform' and 'Electrical/electronical platform' in Figure 2 appear misaligned with the shaded bars; please check the figure's readability and correct the typo 'electronical.'
  4. [Section 1] The paper would benefit from a brief statement of its scope as a perspective white paper, distinguishing it from a systematic review or an empirical study, so readers know what evidence standard to expect.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's transfer claims are framed as testable proposals with explicit gaps, and the evidence mix includes independent external references.

full rationale

After walking the paper's claimed derivation chain, I find no step where a prediction or first-principles result is equivalent to its inputs by construction. The central contribution is a framing (the lifecycle paradox) and a proposed DevOps-style engineering loop, not a derived quantitative claim. Section 4 proposes capabilities; Section 5 assesses them against civilian evidence and explicitly labels the defence transfer as an open gap: 'What remains open is the handoff between these regimes ... is unsolved in both the civilian and defence literature' (Section 5.3), and 'Jamming, spoofing, and sensor denial, the actively adversarial conditions defence autonomy certification requires are next steps' (Section 5.2). The fortiss tools (AutoFOCUS3, OpenSBT, DABBER, neuromorphic lab) appear as illustrative examples of the civilian baseline, but each capability subsection pairs them with an external counterpart (NATO Architecture Framework, DART, DARPA GARD, NASA/JPL ION, Intel Loihi/BrainChip Akida), and Section 5.4 explicitly excludes internally explored but unpublished results from evidence: 'are not yet independently published, and are therefore not presented here as evidence.' The recommendations then ask the community to validate 'an existing search-based testing pipeline, unmodified in its search mechanism, with a fitness objective redirected to the failure class under study' (Section 6.1) — this is a research proposal, not a prediction that has already been forced by a fit. No parameter is fitted to a subset and then 'predicted' on a closely related quantity, and no unique-solution theorem from the authors' prior work is invoked to foreclose alternatives. The paper is therefore self-contained as a perspective piece: its claims are either definitions, explicitly bounded maturity claims, or falsifiable next steps. Minor self-citation exists but is not load-bearing because the central thesis ('civilian-proven capabilities can be redirected') is supported by external benchmarks and by the paper's own insistence on where validation remains missing.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No free parameters or invented physical entities appear. The central claim rests on four assumptions: the validity of CPS engineering foundations, acceptance of the BMVg SDD definition, the accuracy of self-assigned TRL ratings for fortiss tools, and the transferability of DevOps patterns to certified defence contexts.

assumptions (4)
  • domain assumption CPS engineering principles and the acatech agenda provide a sound basis for understanding SDD
    The paper builds on the acatech CPS agenda and Broy's work (Refs 3, 4, 7) as the foundation for characterizing SDD, without re-deriving those results.
  • domain assumption The BMVg position paper's definition of SDD and its central premise (software determines differentiating capabilities) is accepted
    Section 2.3 uses the BMVg/Bitkom position paper (Ref 11) as the definitional starting point without critical examination.
  • ad hoc to paper Technology Readiness Level (TRL) self-assessments by the authors are an accurate measure of maturity
    Each 'Maturity and gap' paragraph in Section 5 assigns TRL 5-6 or 6-7 to fortiss tools based on the authors' own judgment and prior publications, with no independent assessor.
  • domain assumption The DevOps continuous-loop pattern transfers from commercial software to safety- and security-critical defence contexts
    Section 4 assumes DevSecOps and continuous assurance concepts apply to certified military platforms, although Section 3.1 itself notes defence certification was not built for continuous change.

how reviews work

0 comments
Cite this review

Pith. "Pith review of White paper: A perspective on civilian-to-defence research transfer to SDD." pith.science (2026). https://pith.science/paper/2BNGLQ56

@misc{pith2026260809349,
  author       = {Pith},
  title        = {Pith review of: White paper: A perspective on civilian-to-defence research transfer to SDD},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2BNGLQ56}},
  note         = {Machine review of arXiv:2608.09349}
}
read the original abstract

Military capability is increasingly determined by software. Yet defence platforms are procured on decade-long timescales, while the software and AI models they carry must evolve in days or hours. This paper calls this mismatch the lifecycle paradox, and argues it is the central problem Software-Defined Defence (SDD) must solve. SDD rests on three dimensions: software and systems engineering (design, procurement, certification), AI engineering (sovereignty and trust of learned components), and connectivity and infrastructure engineering (timely exchange of information among sensors, AI, and operators). The proposed path to resilient SDD starts from civilian technologies, addressed through a continuous, DevOps-style loop: model-based systems engineering and simulation-based testing front-load design and verification; tactical connectivity and low-power edge execution carry that design into contested operation; continuous compliance, assurance, and variability management run as cross-cutting concerns. This loop is sustainable given capabilities already proven in automotive, manufacturing, space, and energy. The next step is validating them under adversarial or defence-certified conditions, with short-, medium-, and long-term paths to closing gaps. Closing the SDD gap while preserving civic benefits is a distributed responsibility: researchers must redirect methods toward adversarial conditions; industry must expose tooling to operational needs; policymakers must shape regulatory instruments; and defence agencies must validate results with operators. Recommendations span three horizons: a short-term baseline of adversarial testing and connectivity pilots; a medium-term pipeline of incremental certification; and a long-term validation closing the loop under operational conditions.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

98 extracted references · 63 canonical work pages

  1. [1]

    Cyber physical systems: Design challenges,

    E. A. Lee, “Cyber physical systems: Design challenges,” inProceedings of the 11th IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC). IEEE, 2008, pp. 363–369. doi: 10.1109/ISORC.2008.25

    doi:10.1109/isorc.2008.25 2008

  2. [2]

    Cyber-physical systems: The next computing revolution,

    R. Rajkumar, I. Lee, L. Sha, and J. Stankovic, “Cyber-physical systems: The next computing revolution,” inProceedings of the 47th ACM/IEEE Design Automation Conference (DAC). IEEE, 2010, pp. 731–736. doi: 10.1145/1837274.1837461

    work page arXiv 2010

  3. [5]

    Explainable Software for Cyber-Physical Systems (ES4CPS): Report from the GI Dagstuhl Seminar 19023, January 06-11 2019, Schloss Dagstuhl

    J. Greenyer, M. Lochau, and T. Vogel, “Explainable software for cyber-physical systems (ES4CPS): Report from the GI dagstuhl seminar 19023,” Schloss Dagstuhl – Leibniz-Zentrum f ¨ur Informatik, Tech. Rep. 19023, Jan. 2019. doi: 10.48550/arXiv.1904.11851

    work page Pith review arXiv doi:10.48550/arxiv.1904.11851 2019

  4. [6]

    Cyber-Physical Systems: Visionen, Charakteristika und Neue F ¨ahigkeiten,

    E. Geisberger and M. Broy, “Cyber-Physical Systems: Visionen, Charakteristika und Neue F ¨ahigkeiten,” inagendaCPS: Integrierte Forschungsagenda Cyber-Physical Systems, ser. acatech STUDIE, E. Geisberger and M. Broy, Eds. Berlin, Heidelberg: Springer, 2012, vol. 1, pp. 29–68. doi: 10.1007/978-3-642-29099-2 2

    work page doi:10.1007/978-3-642-29099-2 2012

  5. [7]

    M. Broy, E. Geisberger, M. V. Cengarle, P . Keil, J. Niehaus, C. Thiel, and H.-J. Th ¨onnißen-Fries,Cyber-Physical Systems: Innovationsmotor f¨ur Mobilit¨at, Gesundheit, Energie und Produktion, ser. acatech POSITION. Berlin, Heidelberg: Springer, 2012, no. 8. doi: 10.1007/978-3-642-27567-8

    work page doi:10.1007/978-3-642-27567-8 2012

  6. [8]

    SD-CPS: Taming the Challenges of Cyber-Physical Systems with a Software-Defined Approach

    P . Kathiravelu and L. Veiga, “SD-CPS: Taming the challenges of cyber-physical systems with a software-defined ap- proach,” inProceedings of the 4th International Conference on Software Defined Systems (SDS). IEEE, 2017. doi: 10.48550/arXiv.1701.01676

    work page Pith review arXiv doi:10.48550/arxiv.1701.01676 2017

  7. [9]

    Engineering cyber-physical systems: Challenges and foundations,

    M. Broy, “Engineering cyber-physical systems: Challenges and foundations,” inComplex Systems Design & Management, M. Aiguier, Y . Caseau, D. Krob, and A. Rauzy, Eds. Berlin, Heidelberg: Springer, 2013, pp. 1–13. doi: 10.1007/978-3-642- 34404-6 1

    doi:10.1007/978-3-642- 2013

  8. [10]

    Software defined defense: Reliable artificial intelligence for strengthening european defense,

    Fraunhofer Institute for Cognitive Systems IKS, “Software defined defense: Reliable artificial intelligence for strengthening european defense,” Web page, Jun. 2026. [Online]. Available: https://www.iks.fraunhofer.de/en/topics/ software-defined-defense.html

    2026

Show all 98 references
  1. [11]

    Positionspapier Software Defined Defence,

    Bundesministerium der Verteidigung (BMVg), Bundesverband der Deutschen Sicherheits- und Verteidigungsindustrie (BDSV), Bundesverband der Deutschen Luft- und Raumfahrtindustrie (BDLI), and Bundesverband Informationswirtschaft, Telekommunikation und neue Medien (Bitkom), “Positi...

    2023

  2. [12]

    EU defence industry transformation roadmap,

    European Commission, DG DEFIS, “EU defence industry transformation roadmap,” European Commis- sion, Directorate-General for Defence Industry and Space, Tech. Rep., Nov. 2025. [Online]. Avail- able: https://defence-industry-space.ec.europa.eu/document/download/513de692-d08c-40c...

    2025

  3. [13]

    White paper for european defence – readiness 2030,

    European Commission, “White paper for european defence – readiness 2030,” European Commission, Tech. Rep., 2025. [Online]. Available: https://commission.europa.eu/document/download/e6d5db69-e0ab-4bec-9dc0-3867b4373019 en

    2025

  4. [14]

    Trustworthy autonomous/cognitive systems: A structured approach,

    fortiss GmbH, “Trustworthy autonomous/cognitive systems: A structured approach,” for- tiss Whitepaper. [Online]. Available: https://www.fortiss.org/fileadmin/user upload/06 Ergebnisse/Whitepaper/ fortiss-whitepaper-trustworthy-auto-cogn-systems-web.pdf

  5. [15]

    White paper: Towards human-centric and sustainable 6g services -the fortiss research perspective,

    R. C. Sofia, H. Shen, Y . Liu, S. Kacianka, and H. Pfeifer, “White paper: Towards human-centric and sustainable 6g services -the fortiss research perspective,” fortiss GmbH, Tech. Rep., sep 2025. doi: 10.48550/arXiv.2507.14209 . 26 fortiss white paper on civilian to defence te...

    2025 doi arXiv

  6. [16]

    A safety case pattern for systems with machine learning components,

    E. Wozniak, C. C ˆarlan, E. Acar-Celik, and H. J. Putzer, “A safety case pattern for systems with machine learning components,” inProceedings of the International Conference on Computer Safety, Reliability, and Security (SAFECOMP), ser. LNCS, vol. 12235. Springer, Sep. 2020, p...

    2020 doi

  7. [17]

    European defence fund: 2026 annual work programme,

    European Commission, “European defence fund: 2026 annual work programme,” European Commission, Tech. Rep., Dec

    2026

  8. [18]

    Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (cyber resilience act),

    European Parliament and Council of the European Union, “Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (cyber resilience act),” Official Journal of the European Union, Oct. 2024. [Online]. Available: https://eur-lex.europa...

    2024

  9. [19]

    UAV digital platform for first-response operations, daily transports, and data acquisition,

    J. Harttunen, D. H ¨astbacka, H. Edelman, J. Stenroos, M. Kauppinen, and J. R ¨oning, “UAV digital platform for first-response operations, daily transports, and data acquisition,” 2025, tampere University and University of Oulu, Finland. [Online]. Available: https://www.scienc...

    2025

  10. [20]

    An ebpf-based programmable network architecture for OT digital resilience use-cases,

    F . Holik, S. Jouet, and D. Pezaros, “An ebpf-based programmable network architecture for OT digital resilience use-cases,” in2025 IEEE Symposium on Computers and Communications (ISCC), 2026. doi: 10.1109/ISCC65549.2025.11325939 ., university of Glasgow, UK

    2026

  11. [21]

    Cyber-Physical Systems — Wissenschaftliche Herausforderungen bei der Entwicklung,

    M. Broy, “Cyber-Physical Systems — Wissenschaftliche Herausforderungen bei der Entwicklung,” inCyber-Physical Systems: Innovation durch softwareintensive eingebettete Systeme, ser. acatech DISKUTIERT, M. Broy, Ed. Berlin, Heidelberg: Springer, 2010, pp. 17–34. doi: 10.1007/978...

    2010 doi

  12. [22]

    Adversarial machine learning in industry: A systematic literature review,

    F . V. Jedrzejewski, L. Thode, J. Fischbach, T. Gorschek, D. Mendez, and N. Lavesson, “Adversarial machine learning in industry: A systematic literature review,”Computers & Security, vol. 145, p. 103988, 2024

    2024

  13. [23]

    Latest advances on deterministic wired/wireless industrial networks,

    R. C. Sofia, “Latest advances on deterministic wired/wireless industrial networks,” in6G Connectivity: Systems, Technologies, and Applications. River Publishers, 2024. doi: 10.1201/9781003515920-10

    2024 doi

  14. [24]

    Bundle Protocol Version 7,

    B. Scott and S. Burleigh, “Bundle Protocol Version 7,” RFC 9171, Internet Engineering Task Force, RFC 9171, Jan. 2022. doi: 10.17487/RFC9171

    2022 doi

  15. [25]

    Named data networking,

    L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, kc claffy, P . Crowley, C. Papadopoulos, L. Wang, and B. Zhang, “Named data networking,”ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 66–73, 2014. doi: 10.1145/2656877.2656887

    2014

  16. [26]

    ISO 26262: Road vehicles – functional safety,

    “ISO 26262: Road vehicles – functional safety,” https://www.iso.org/standard/68383.html, International Organization for Stan- dardization, 2018

    2018

  17. [27]

    STPA handbook,

    N. G. Leveson and J. P . Thomas, “STPA handbook,” http://psas.scripts.mit.edu/home/get file.php?name=STPA handbook. pdf, MIT Partnership for Systems Approaches to Safety and Security, Tech. Rep., 2018

    2018

  18. [28]

    IEC 61025: Fault tree analysis (fta),

    “IEC 61025: Fault tree analysis (fta),” https://webstore.iec.ch/publication/4311, International Electrotechnical Commission, 2006

    2006

  19. [29]

    ISO/SAE 21434: Road vehicles – cybersecurity engineering,

    “ISO/SAE 21434: Road vehicles – cybersecurity engineering,” https://www.iso.org/standard/70918.html, International Orga- nization for Standardization and SAE International, 2021

    2021

  20. [30]

    IEC 60812: Failure modes and effects analysis (fmea and fmeca),

    “IEC 60812: Failure modes and effects analysis (fmea and fmeca),” https://webstore.iec.ch/publication/26359, International Electrotechnical Commission, 2018

    2018

  21. [31]

    A Framework for the Deterministic Networking (DetNet) Controller Plane,

    A. G. Malis, X. Geng, M. Chen, B. Varga, and C. J. Bernardos, “A Framework for the Deterministic Networking (DetNet) Controller Plane,” RFC 9938, Mar. 2026. doi: 10.17487/RFC9938

    2026 doi

  22. [32]

    Delay-tolerant networking management architecture (DTNMA),

    E. J. B. III, S. Heiner, and E. Annis, “Delay-tolerant networking management architecture (DTNMA),” IETF , RFC 9675, Nov

  23. [33]

    Supporting military communications with named data networking: An emulation analysis,

    B. Etefia, M. Gerla, and L. Zhang, “Supporting military communications with named data networking: An emulation analysis,” inProceedings of IEEE MILCOM 2012. IEEE, 2012. doi: 10.1109/MILCOM.2012.6415685

    2012

  24. [34]

    Using MQTT to support mobile tactical force situational awareness,

    F . T. Johnsenet al., “Using MQTT to support mobile tactical force situational awareness,” in2018 International Conference on Military Communications and Information Systems (ICMCIS). IEEE, 2018. doi: 10.1109/ICMCIS.2018.8398732 . 27 fortiss white paper on civilian to defence ...

    2018

  25. [35]

    Summary of nato’s revised artificial intelligence strategy,

    North Atlantic Treaty Organization (NATO), “Summary of nato’s revised artificial intelligence strategy,” NATO Official Text, Jul. 2024. [Online]. Available: https://www.nato.int/en/about-us/official-texts-and-resources/official-texts/2024/07/10/ summary-of-natos-revised-artifi...

    2024

  26. [36]

    Bayha, S

    A. Bayha, S. Bergemann, W. B ¨ohm, J. Philipps, A. Vogelsang, and S. Voss,Model-Based Systems Engineering with the SPES Modeling Language: Usage of the Language Constructs in the SPES Methodology. GfSE Verlag, Jan. 2025, pp. 63 –118. [Online]. Available: https://www.gfse.org/d...

    2025

  27. [37]

    Hardware architecture exploration: automatic exploration of distributed automotive hardware architectures,

    J. Eder, S. Voss, A. Bayha, A. Ipatiov, and M. Khalil, “Hardware architecture exploration: automatic exploration of distributed automotive hardware architectures,”Software and Systems Modeling, vol. 19, pp. 911–934, Jul. 2020. doi: 10.1007/s10270- 020-00786-6

    2020 doi

  28. [38]

    A toolchain for synthesizing and validating safety architectures,

    Y . G. Dantas, T. Munaro, C. Cˆarlan, V. Nigam, S. Barner, S. Fan, A. Pretschner, U. Sch¨opp, and S. Tverdyshev, “A toolchain for synthesizing and validating safety architectures,”SN Computer Science, vol. 4, no. 4, p. 335, Apr. 2023. doi: 10.1007/s42979- 023-01712-5

    2023 doi

  29. [39]

    Safety-aware deployment synthesis and trade-off analysis of apollo autonomous driving platform,

    T. Terzimehi ´c, S. Barner, Y . G. Dantas, U. Sch¨opp, V. Nigam, and P . Ke, “Safety-aware deployment synthesis and trade-off analysis of apollo autonomous driving platform,” in9th International Workshop on Automotive System/Software Architectures (WASA) co-located with ICSA 2...

    2023

  30. [40]

    Komplexit ¨atsbeherrschung und Aufwandsreduktion in der Avioniksystementwicklung,

    T. Munaro, A. Schweiger, S. Voss, J. Eder, and S. Barner, “Komplexit ¨atsbeherrschung und Aufwandsreduktion in der Avioniksystementwicklung,”Informatik Spektrum, vol. 48, no. 5, pp. 128–147, Apr. 2025. doi: 10.1007/s00287-025-01592-4

    2025 doi

  31. [41]

    2026, document version 2026.03

    NATO Architecture Capability Team,NATO Architecture Framework, Version 4.1, NATO Digital Policy Committee, Mar. 2026, document version 2026.03. [Online]. Available: https://www.nato.int/content/dam/nato/webready/documents/ publications-and-reports/NATO-Architecture-Framework-v...

    2026

  32. [42]

    DART: Digital architecture framework for sos readiness and digital twin integration,

    European Commission, Directorate-General for Defence Industry and Space, “DART: Digital architecture framework for sos readiness and digital twin integration,” European Defence Fund selected project factsheet, 2025, eDF 2025 Research Action; combines Digital Twins, MBSE, and s...

    2025

  33. [43]

    OpenSBT: A modular framework for search-based testing of automated driving systems,

    L. Sorokin, T. Munaro, D. Safin, B. H.-C. Liao, and A. Molin, “OpenSBT: A modular framework for search-based testing of automated driving systems,” inProceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion)....

    2024

  34. [44]

    A systematic approach to fault injection test case generation in practice,

    T. Munaro, M. Turalija, S. Barner, and M. Halak, “A systematic approach to fault injection test case generation in practice,” in Software Engineering and Advanced Applications. Springer, Sep. 2025, pp. 201–218. doi: 10.1007/978-3-032-04190-6 13

    2025 doi

  35. [45]

    Simulator ensembles for trustworthy autonomous driving systems testing,

    L. Sorokin, M. Biagiola, and A. Stocco, “Simulator ensembles for trustworthy autonomous driving systems testing,”Empirical Software Engineering, vol. 31, no. 4, Feb. 2026. doi: 10.1007/s10664-026-10821-7

    2026 doi

  36. [46]

    Fine Time Measurement Based Synchronisation for Industrial Wireless/Wired Networks,

    S. H. Mohan and R. C. Sofia, “Fine Time Measurement Based Synchronisation for Industrial Wireless/Wired Networks,” in Proceedings of IEEE WPMC 2022. IEEE, Nov. 2022. doi: 10.1109/WPMC55625.2022.10014703

    2022

  37. [47]

    Fine time measurement based time synchronization for multi-ap wireless industrial environments,

    ——, “Fine time measurement based time synchronization for multi-ap wireless industrial environments,” in2023 19th Inter- national Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), 2023, pp. 399–404. doi: 10.1109/WiMob58348.2023.10187788

    2023

  38. [48]

    A proposal for time-aware scheduling in wireless industrial iot envi- ronments,

    B. Schneider, R. C. Sofia, and M. Kovatsch, “A proposal for time-aware scheduling in wireless industrial iot envi- ronments,” inNOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, 2022, pp. 1–6. doi: 10.1109/NOMS54207.2022.9789864

    2022

  39. [49]

    Requirements for reliable wireless industrial services,

    R. C. Sofia, P . Mendes, C. J. Bernardos, and E. Schooler, “Requirements for reliable wireless industrial services,” IETF , Internet-Draft draft-ietf-detnet-raw-industrial-req-01, Jul. 2024. [Online]. Available: https://datatracker.ietf.org/doc/html/ draft-ietf-detnet-raw-indu...

    2024

  40. [50]

    Reliable and available wireless (RAW) architecture,

    P . Thubert, “Reliable and available wireless (RAW) architecture,” IETF , RFC 9912, Apr. 2026. doi: 10.17487/RFC9912

    2026 doi

  41. [51]

    Information-centric routing for opportunistic wireless networks (DABBER),

    P . Mendes, R. C. Sofia, V. Tsaoussidis, and C. Borrego, “Information-centric routing for opportunistic wireless networks (DABBER),” IETF ICNRG Internet-Draft (Experimental), draft-mendes-icnrg-dabber-05, Sep. 2020. [Online]. Available: https://datatracker.ietf.org/doc/draft-m...

    2020

  42. [52]

    Intermittently-connected IoT devices: Experiments with an NDN- DTN architecture,

    R. C. Sofia, P . Mendes, V. Tsaoussidis, and C. Borrego, “Intermittently-connected IoT devices: Experiments with an NDN- DTN architecture,” in2021 IEEE 18th Annual Consumer Communications and Networking Conference (CCNC). IEEE, Jan

  43. [53]

    CLANE: Continual learning of actions on neuromorphic hardware from event cameras,

    E. Hajizada, M. Neumeier, E. P . Frady, Y . Sandamirskaya, A. von Arnim, B. Li, and E. H ¨ullermeier, “CLANE: Continual learning of actions on neuromorphic hardware from event cameras,”arXiv preprint, 2026. doi: arXiv:2605.28387 . [Online]. Available: https://arxiv.org/abs/2605.28387

    2026 arXiv

  44. [54]

    EEvAct: Early event-based action recognition with high-rate two-stream spiking neural networks,

    M. Neumeier, J. Lecomte, N. Kazinski, S. Banik, B. Li, and A. von Arnim, “EEvAct: Early event-based action recognition with high-rate two-stream spiking neural networks,” inProceedings of the International Conference on Neuromorphic Systems (ICONS 2025). IEEE Press, 2025, pp. ...

    2025

  45. [55]

    Event-driven optical marker tracking on neuromorphic hardware,

    A. von Arnim, M. Neumeier, B. Li, and Y . Sandamirskaya, “Event-driven optical marker tracking on neuromorphic hardware,”Frontiers in Neurorobotics, vol. 18, 2024. doi: 10.3389/fnbot.2024.1290965 . [Online]. Available: https://www.frontiersin.org/articles/10.3389/fnbot.2024.1290965

    2024

  46. [57]

    Aligning security compliance and devops: A longitudinal study,

    F . Moy´on, F . Angermeir, D. Mendez, T. Gorschek, M. Voggenreiter, and P .-L. Bonvin, “Aligning security compliance and devops: A longitudinal study,”Journal of Systems and Software, vol. 234, p. 112718, 2026. doi: 10.1016/j.jss.2025.112718

    2026

  47. [58]

    Towards automated continuous security compliance,

    F . Angermeir, J. Fischbach, F . Moy´on, and D. Mendez, “Towards automated continuous security compliance,” inProceedings of the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ACM, 2024, pp. 440–446. doi: 10.1145/3674805.3690748

    2024

  48. [59]

    In- vestigating automated change analysis in FinTech regulations,

    P . Elahidoost, H. Villamizar, F . Angermeir, J. Streit, D. Mendez, M. Unterkalmsteiner, and T. Gorschek, “In- vestigating automated change analysis in FinTech regulations,”Information and Software Technology, 2026. doi: https://doi.org/10.1016/j.infsof.2026.108144

    2026

  49. [60]

    Knowledge-augmented security risk identification for ot container deployments,

    Y . Landeck, T. Bueno Momˇcilovi´c, D. Balta, M. Wimmer, and C. Knierim, “Knowledge-augmented security risk identification for ot container deployments,” in24th International Semantic Web Conference: Companion Volume (ISWC-C 2025). Nara, Japan: CEUR Workshop Proceedings, Nov. ...

    2025

  50. [61]

    Automated security findings management: A case study in industrial devops,

    M. Voggenreiter, F . Angermeir, F . Moy´on, U. Sch¨opp, and P . Bonvin, “Automated security findings management: A case study in industrial devops,” inProceedings of the 46th International Conference on Software Engineering: Software Engineering in Practice. ACM, 2024, pp. 312...

    2024

  51. [62]

    System- atic mapping study on requirements engineering for regulatory compliance of software systems,

    O. Kosenkov, P . Elahidoost, T. Gorschek, J. Fischbach, D. Mendez, M. Unterkalmsteiner, D. Fucci, and R. Mohanani, “System- atic mapping study on requirements engineering for regulatory compliance of software systems,”Information and Software Technology, vol. 178, p. 107622, 2...

    2025

  52. [63]

    Generic analysis of model product lines via constraint lifting,

    A. Bayha and V. Aravantinos, “Generic analysis of model product lines via constraint lifting,” arXiv:2008.11427 [cs.SE], Aug

    2008 arXiv

  53. [64]

    Building product-lines of mixed-criticality systems,

    S. Barner, A. Diewald, F . Eizaguirre, A. Vasilevskiy, and F . Chauvel, “Building product-lines of mixed-criticality systems,” in Proceedings of the Forum on Specification and Design Languages (FDL 2016). Bremen, Germany: IEEE, Sep. 2016. doi: 10.1109/FDL.2016.7880378

    2016

  54. [65]

    RMC factory: A new approach for avionics software reuse,

    L. Dieudonne, A. Bayha, and B. M ¨uller, “RMC factory: A new approach for avionics software reuse,” in3rd Workshop on Avionics Systems and Software Engineering (AvioSE21, SE 2021 Satellite Events), vol. 2814. CEUR-WS, Feb. 2021. [Online]. Available: http://ceur-ws.org/Vol-2814...

    2021

  55. [66]

    Exploratory analysis of wi-fi 6 dynamic resource unit sharing in small-scale network scenarios,

    S. Mada, A. Baron, L. Martino, and R. C. Sofia, “Exploratory analysis of wi-fi 6 dynamic resource unit sharing in small-scale network scenarios,” 2026. [Online]. Available: https://arxiv.org/abs/2606.11934 29 fortiss white paper on civilian to defence technology transfer for SDD 2026

    2026 arXiv

  56. [67]

    doi: 10.48550/arXiv.2008.11427

    2008 doi arXiv

  57. [68]

    A CODECO case study and initial validation for edge orchestration of autonomous mobile robots,

    H. Zhu, T. Samizadeh, and R. C. Sofia, “A CODECO case study and initial validation for edge orchestration of autonomous mobile robots,”IEEE Computer, May 2026. doi: 10.1109/MC.2025.3643725

    2026

  58. [69]

    Spikeclouds: Streaming spike-based processing of lidar for fast and efficient object detection,

    M. Neumeier, N. Fasfous, B. Li, and A. von Arnim, “Spikeclouds: Streaming spike-based processing of lidar for fast and efficient object detection,”IEEE Robotics and Automation Letters, vol. 10, no. 8, pp. 8411–8418, 2025. doi: 10.1109/LRA.2025.3585394 . 7 Referenced Web Source...

    2025

  59. [71]

    Towards scalable federated container orchestration: The codeco approach,

    R. C. Sofia, J. Salomon, R. Carrol, L. Garc ´es-Erice, P . Urbanetz, J. Gesswein, R. Touma, A. Espinosa, L. M. Contreras, V. Theodorou, G. Papathanail, G. Koukis, V. Tsaoussidis, A. del Rio, D. Jimenez, E. Paraskevoulakou, P . Karamolegkos, J. Soldatos, B. D. Nogales, and A. T...

  60. [75]

    German National Academy of Science and Engineering (acatech) — en.acatech.de

  61. [76]

    OWASP Top 10 (2025) — owasp.org/Top10/2025

    2025

  62. [77]

    Corvus Intelligence, European defence tech market 2025 — corvusintell.com/blog/defense-tech-market-europe-2025

    2025

  63. [78]

    Council on Foreign Relations, NATO 2% spending milestone — cfr.org/expert-brief/nato-2-percent-spending

  64. [79]

    German Federal Ministry of Defence (BMVg), Bundeswehr special fund (Sonderverm ¨ogen) — bmvg.de/en/news/over-eur- 100-billion-bundeswehr

  65. [80]

    Bundeswehr, D-LBO digitalisation programme — bundeswehr.de/de/meldungen/digitalisierung-landbasierte-operationen

  66. [81]

    Arquus, French SCORPION programme — arquus-defense.com/scorpion-program

  67. [82]

    European Commission, SAFE loan instrument — commission.europa.eu/topics/defence/future-european-defence

  68. [83]

    European Commission, AGILE fast-fielding fund — commission.europa.eu/priorities-2024-2029/security-and-defence

    2024

  69. [84]

    NATO, Revised Artificial Intelligence Strategy (2024) — nato.int, Revised AI Strategy (2024)

    2024

  70. [85]

    EURO-3C, federated Telco-Edge-Cloud (3C) infrastructure project — euro-3c.eu

  71. [86]

    Fraunhofer, multi-agent reinforcement learning and autonomous cooperation — safe-intelligence.fraunhofer.de, multi-agent RL article

  72. [87]

    SeRANIS, B5G/6G laboratory environment — seranis.de

  73. [88]

    dtec.bw, SeRANIS project page — dtecbw.de, SeRANIS project page

  74. [89]

    Fraunhofer IKS, Software-Defined Defense — iks.fraunhofer.de/en/topics/software-defined-defense

  75. [90]

    Sylva Project, open-source telco cloud stack — sylvaproject.org

  76. [91]

    CODECO, cognitive decentralised edge-cloud orchestration — he-codeco.eu

  77. [92]

    Object Management Group (OMG), Data Distribution Service (DDS) portal — omg.org/omg-dds-portal

  78. [93]

    DARPA, SyNAPSE programme — darpa.mil, SyNAPSE programme

  79. [94]

    fortiss, AutoFOCUS3 (AF3) MBSE platform — af3.fortiss.org

  80. [95]

    NASA/JPL, Interplanetary Overlay Network — nasa.gov, Interplanetary Overlay Network

  81. [96]

    Intel, Loihi 2 neuromorphic computing technology brief — intel.com, Loihi 2 technology brief

  82. [97]

    DARPA, Guaranteeing AI Robustness against Deception (GARD) programme — darpa.mil, GARD programme

  83. [98]

    EU AI Act Compliance Checker — artificialintelligenceact.eu, Compliance Checker

  84. [99]

    fortiss, Evidential Tool Bus — fortiss.org, Evidential Tool Bus

  85. [100]

    fortiss, FOCETA project — fortiss.org, FOCETA project

  86. [101]

    KI Wissen project — kiwissen.de 30 fortiss white paper on civilian to defence technology transfer for SDD 2026 A Research Infrastructures Referenced in this Paper •fortiss Mobility Lab(AutoFOCUS3, architecture exploration, OpenSBT) —https://www.fortiss.org/forschung/fortiss-la...

    2026

  87. [2021]

    doi: 10.1109/CCNC49032.2021.9369578

    2021

  88. [2024]

    doi: 10.17487/RFC9675

    doi

  89. [2025]

    Available: https://defence-industry-space.ec.europa.eu/edf-work-programme-2026 en

    [Online]. Available: https://defence-industry-space.ec.europa.eu/edf-work-programme-2026 en

    2026

  90. [2026]

    Available: https://arxiv.org/abs/2601.13351

    [Online]. Available: https://arxiv.org/abs/2601.13351

Pith tools

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