Pith. sign in

REVIEW 3 major objections 5 minor 55 references

A Case Study of API Design for Interoperability and Security of the Internet of Things

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

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

Pith's one-line read The paper claims that a seven-function API and runtime can give heterogeneous IoT devices both interoperability across communication models and optional security, with small overhead.

desk verdict A real API/runtime integration for Lingua Franca whose headline 'reasonably small overhead' is contradicted by its own MQTT measurement; fixable in revision, but misleading as published. read the letter →

arxiv 2411.13441 v1 pith:JPBG5EUY submitted 2024-11-20 cs.DC cs.SYeess.SY

Dongha Kim , Chanhee Lee , Hokeun Kim This is my paper · ORCID
classification cs.DCcs.SYeess.SY
keywords InternetofThingsInteroperabilitySecurityAPIDesignPublish-SubscribePoint-to-PointCommunicationEdgeComputingOverheadEvaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper argues that a single small API, with seven functions for connection setup, data transfer, and teardown, can hide the differences between point-to-point and publish-subscribe communication and can add optional authentication and encryption. The aim is to let heterogeneous IoT and cyber-physical systems interoperate without each application being rewritten for a particular protocol or security level. The authors implement the API on top of open-source coordination and security components and measure communication latency, message size, and binary size. Their reported overhead is small for the TCP and encrypted paths, while the publish-subscribe path currently carries a much larger latency, a limitation the paper acknowledges.

What carries the argument

The carrying mechanism is the network driver (netdriver), a small abstraction layer that gives the seven API functions a uniform interface while hiding protocol details behind a void pointer cast to a protocol-specific struct for TCP, MQTT, or the secure session mode. It also contains the bookkeeping for reading complete application-level messages, using a state machine that distinguishes fixed-length, structured variable-length, and variable-length messages, which is necessary because TCP is a byte stream and the other protocols carry their own lengths. This layer is what lets the same federated program be compiled once with a communication-type choice and run over different stacks without changes to application code.

What would settle it

Re-run the paper's HelloDistributed federation with MQTT in centralized coordination and a 50 ms message period; if the average lag stays near the reported 188 ms rather than approaching the 4.4 ms TCP baseline, the publish-subscribe mode does not achieve the reasonably-small-overhead claim.

Watch

Extended reading notes

Core claim

The central claim is that the proposed API and runtime can deliver interoperability and security for IoT and distributed cyber-physical systems with reasonably small overhead and better-managed software. The API defines a Listener and a Connector node and exposes seven functions -- create_listener, create_connector, wait_for_connection, connect, read, write, and close -- that map onto a client-server model such as TCP and, through a three-way handshake over named topics, onto a publish-subscribe model such as MQTT. When security is enabled, the runtime obtains a session key from a key distribution center, uses message authentication codes for integrity and block-cipher encryption for confidentiality, and destroys the key on close. The implementation wraps these protocols behind a polymorphic network driver and conditionally compiles only the needed libraries. The measured TCP lag is close to the baseline, and the secure session mode adds only a small increase; the MQTT mode, however, shows an average lag around 188 milliseconds, which the paper attributes to synchronous delivery guarantees and centralized coordination.

Load-bearing premise

The reasonably-small-overhead claim rests on the assumption that the API's synchronous read() and write() can be layered on an MQTT broker without losing the low latency of the TCP path; the paper's own measurement puts MQTT average lag at about 188 ms versus 4.4 ms for the baseline, so that assumption is not currently met for publish-subscribe.

Editorial extensions

If this is right

  • Application code written against the seven functions does not need to change when the underlying protocol is switched from TCP to MQTT or to the secure mode; the switch happens at compile time through the communication-type option.
  • Enabling authentication and encryption adds only a small latency cost in the TCP case, so security can be turned on for sessions that need it without redesigning the application.
  • The message-boundary state machine lets a byte-stream protocol like TCP carry messages that other protocols already delimit, which is a prerequisite for mixing protocols behind one API.
  • In the current implementation, publish-subscribe over MQTT has substantially higher latency than TCP, so before the reasonably-small-overhead claim extends to pub-sub, the runtime must avoid the double-broker bottleneck or use decentralized coordination.
  • The decoupled network-driver design is claimed to improve modularity and information hiding; the paper's qualitative analysis finds all six standard coupling types avoided.

Reading between the lines

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

  • If the MQTT latency gap is closed, protocol selection could become a deployment-time property, letting constrained devices use pub-sub while control loops use TCP without forking the application code.
  • The three-way handshake over named topics could be ported to brokerless pub-sub systems, where discovery would replace the centralized coordinator and the 188 ms bottleneck might disappear.
  • The state-machine approach to message boundaries is a reusable pattern for retrofitting message framing onto any stream transport, not just TCP.
  • A natural next test is a single federation whose nodes deliberately use different communication modes; the paper states this is future work, so until demonstrated, the interoperability claim is per-protocol rather than cross-protocol within one running system.
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

3 major / 5 minor

Summary. This paper presents a case study of a seven-function API (create_listener, create_connector, wait_for_connection, connect, read, write, close) implemented on top of the Lingua Franca runtime. The API is realized through a network driver (netdriver) that abstracts TCP, MQTT, and the Secure Swarm Toolkit (SST), with optional KDC-based authentication and encryption. The authors evaluate communication lag, message size, binary size, and software-design modularity in a setup with two Raspberry Pi 4 federates and an edge workstation. The paper claims that the approach provides IoT/CPS interoperability and security with reasonably small overhead and better-managed software.

Significance. The main value of the paper is a working, open-source implementation that exposes a uniform API over multiple communication stacks and integrates an existing security toolkit into an established coordination runtime. The netdriver state machine for TCP message-boundary handling and the concrete integration of SST with LF are useful engineering contributions. The evaluation is direct, and the latency results for TCP and SST modes are clean and small. However, the significance is limited by claim overreach: the MQTT measurement contradicts the 'reasonably small overhead' claim, and the interoperability claim is not tested in a mixed-mode federation. If these claims are scoped down and the MQTT path is either improved or clearly presented as a limitation, the case study could be a useful practical report for the community.

major comments (3)
  1. [§5.2, Fig. 8 and Abstract] The abstract's claim of 'reasonably small overhead' is contradicted by the paper's own MQTT measurement. In the same setup, the average lag for MQTT is 188 ms versus about 4.4–5.1 ms for the baseline, TCP, and SST modes, a factor of roughly 37–43. The text explains that the synchronous MQTTClient_waitForCompletion() call and centralized RTI relaying cause netdrv_write() to run twice per logical message, at about 90 ms per call. Section 5.2 concedes that centralized coordination becomes inefficient for MQTT, and §5.4 states that decentralized coordination currently supports only TCP. Since publish-subscribe is one of the two communication models the API explicitly claims to support in §3.2, the unqualified overhead claim must be restricted to TCP/SST or the MQTT path must be redesigned and re-measured.
  2. [§3.2 and §6] The 'interoperability' claim is not directly demonstrated by the evaluation. In the experiments, a federation is configured with a single comm-type, as in Fig. 5b line 3, so the results show that the same API can be mapped onto TCP, MQTT, or SST individually, not that nodes using different communication models can interact within one federation. The conclusion and future-work section explicitly lists 'allow distributed nodes with different communication modes to join a single federation' as future work. To support the abstract's interoperability claim, the paper should either present a mixed-mode federation experiment or reword the claim as portability across communication stacks.
  3. [§5.5] The software-design analysis claims that the design 'does not pass any data between modules' and therefore avoids all six types of coupling. This is contradicted by the API itself: read() and write() transfer message payloads, and the netdriver in §4.3 and §4.5 passes data pointers and protocol-specific structures such as socket_priv_t, sst_priv_t, and MQTT_priv_t between the abstraction and implementation layers. The coupling analysis should be revised to acknowledge data coupling through parameters; as written, the qualitative support for the 'better-managed software' claim is not accurate.
minor comments (5)
  1. [§5.2, Fig. 8] The lag results are reported only as averages, with no error bars, confidence intervals, or number of repetitions; please add this information so the reader can assess variability, especially for the 188 ms MQTT figure.
  2. [§5.1] The experimental setup gives workstation and Raspberry Pi hardware but does not specify the OS, library versions (e.g., Eclipse Paho, Mosquitto, LF, SST), or Wi-Fi conditions; including these would improve reproducibility.
  3. [§4.4 and Fig. 3] There are minor typos: 'API deisgn' in the §4.4 heading and 'Subscirbeto' in Fig. 3; these should be corrected.
  4. [§5.3] The topic name reported for the MQTT message size, 'MQTTTest fed0 to RTI', does not match the naming scheme 'federationID_listenerID' described in §3.2; please clarify the actual topic names used in the measurement.
  5. [§5.4] The binary-size differences for MQTT versus TCP/SST are attributed to speculation about compiler optimizations; since binary-size overhead is one of the stated evaluation metrics, a short verification (e.g., checking linked libraries) would strengthen the discussion.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: all performance claims are measured against an external baseline LF implementation, with no fitted parameters or self-citation chain bearing the central result.

full rationale

The paper is an engineering case study: it proposes an API, implements it with LF and SST, and evaluates overhead by direct measurement against the baseline LF code. The central claims about interoperability and security are supported by a working implementation and by measured metrics (lag, message size, binary size), not by equations derived from the authors' own prior results. The self-citations to SST and LF describe components used in the implementation, but the evaluation compares those components to an external baseline and does not rely on those prior papers' conclusions as evidence for the present claims. The paper's own limitation statements—e.g., that centralized MQTT coordination causes 188 ms average lag and that decentralized MQTT support is future work—undermine the abstract's 'reasonably small overhead' claim for publish-subscribe mode, but that is a correctness or robustness concern, not circularity. No fitted parameter is renamed as a prediction, no definition is circular, and no load-bearing argument reduces to a self-citation. Therefore the circularity score is 0.

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

The central claim rests on deployment assumptions (pre-shared federationID, reachable coordinator and KDC) and on the synchronous MQTT mapping, which the data shows to be slow. There are no fitted free parameters because the evaluation is a case study, not a modeling exercise.

assumptions (4)
  • domain assumption All distributed nodes know the federationID and the IP address/port number of the centralized coordinator before the federation starts.
    Section 3.2 states this assumption; the pub-sub session establishment handshake depends on it.
  • domain assumption A trusted key distribution center (KDC) is available to generate and distribute session keys when security is enabled.
    Section 3.3 introduces the KDC, and the security flow depends on it for authentication and key exchange.
  • domain assumption MQTT with QoS level 2 and synchronous waitForCompletion preserves the ordering and determinism required by Lingua Franca.
    Section 5.2 states that QoS 2 is needed for deterministic timing; the resulting 188 ms lag shows this assumption has a large performance cost.
  • domain assumption The centralized RTI mediates all messages between federates without changing the application-level behavior of the LF program.
    Sections 4.3 and 5.2 describe centralized coordination where the RTI acts as a broker; the MQTT evaluation is run under this mode.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Case Study of API Design for Interoperability and Security of the Internet of Things." pith.science (2026). https://pith.science/paper/JPBG5EUY

@misc{pith2026241113441,
  author       = {Pith},
  title        = {Pith review of: A Case Study of API Design for Interoperability and Security of the Internet of Things},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JPBG5EUY}},
  note         = {Machine review of arXiv:2411.13441}
}
read the original abstract

Heterogeneous distributed systems, including the Internet of Things (IoT) or distributed cyber-physical systems (CPS), often suffer a lack of interoperability and security, which hinders the wider deployment of such systems. Specifically, the different levels of security requirements and the heterogeneity in terms of communication models, for instance, point-to-point vs. publish-subscribe, are the example challenges of IoT and distributed CPS consisting of heterogeneous devices and applications. In this paper, we propose a working application programming interface (API) and runtime to enhance interoperability and security while addressing the challenges that stem from the heterogeneity in the IoT and distributed CPS. In our case study, we design and implement our application programming interface (API) design approach using open-source software, and with our working implementation, we evaluate the effectiveness of our proposed approach. Our experimental results suggest that our approach can achieve both interoperability and security in the IoT and distributed CPS with a reasonably small overhead and better-managed software.

Figures

Figures reproduced from arXiv: 2411.13441 by the authors.

Figure 1
Figure 1. Proposed API functions. Functions with * are blocking functions. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Proposed API functions. Functions with * are blocking functions. These [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Execution model of the proposed API for publish-subscribe communica [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Execution model of the proposed API with security enabled. Functions [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Example of a simple Lingua Franca program. [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: The structure of the netdriver. The void pointer in netdrv t is cast to another struct depending on the network type for polymorphism. pointer depending on the communication type. This enables providing a unified interface for multiple communication protocols. The deta…
Figure 7
Figure 7. Figure 7: The simplified state machine for the netdrv read(). The boldface are the states and italic is the input. number of structures of ‘n,’ followed by ‘n’ fixed-length structures. Finally, the variable length has an integer ‘n’ indicating the length of the payload, followed…
Figure 8
Figure 8. Figure 8: Average lag compared with the baseline LF code. The federate [PITH_FULL_IMAGE:figures/full_fig_p016_8.png]
Figure 9
Figure 9. Figure 9: Sizes of messages sent over the network in bytes for different communica [PITH_FULL_IMAGE:figures/full_fig_p017_9.png]
Figure 10
Figure 10. Figure 10: Binary size in kilobytes compared with the baseline LF code. [PITH_FULL_IMAGE:figures/full_fig_p018_10.png]
Figure 11
Figure 11. Figure 11: Improved software architecture after applying the proposed API design [PITH_FULL_IMAGE:figures/full_fig_p019_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 52 canonical work pages

  1. [1]

    OASIS Standard (2014), https://docs.oasis- open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

    MQTT Version 3.1.1. OASIS Standard (2014), https://docs.oasis- open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

    work page 2014

  2. [2]

    Security and privacy preserving for IoT and 5G networks: techniques, challenges, and new directions pp

    Abounassar, E.M., El-Kafrawy, P., Abd El-Latif, A.A.: Security and interoperabil- ity issues with Internet of things (IoT) in healthcare industry: A survey. Security and privacy preserving for IoT and 5G networks: techniques, challenges, and new directions pp. 159–189 (2022)

    work page 2022

  3. [3]

    IEEE Access 10, 36416–36428 (2022)

    Albouq, S.S., Sen, A.A.A., Almashf, N., Mohammad Yamin, A.A., Bahbouh, N.M.: A survey of interoperability challenges and solutions for dealing with them in IoT environment. IEEE Access 10, 36416–36428 (2022)

    work page 2022

  4. [4]

    Ieee Access 9, 96528–96545 (2021)

    Amjad, A., Azam, F., Anwar, M.W., Butt, W.H.: A systematic review on the data interoperability of application layer protocols in industrial IoT. Ieee Access 9, 96528–96545 (2021)

    work page 2021

  5. [5]

    Arduino: Arduino: Open-source electronics platform (2005), https://www.arduino.cc/

    work page 2005

  6. [6]

    In: Proceedings of the 21st ACM-IEEE International Conference on Formal Methods and Models for System Design

    Bateni, S., Lohstroh, M., Wong, H.S., Kim, H., Lin, S., Menard, C., Lee, E.A.: Risk and mitigation of nondeterminism in distributed cyber-physical systems. In: Proceedings of the 21st ACM-IEEE International Conference on Formal Methods and Models for System Design. pp. 1–11 (2023)

    work page 2023

  7. [7]

    Elsevier (2006)

    Beale, J., Orebaugh, A., Ramirez, G.: Wireshark & Ethereal network protocol analyzer toolkit. Elsevier (2006)

    work page 2006

  8. [8]

    Computing 103(5), 993–1023 (2021)

    Carvalho, G., Cabral, B., Pereira, V., Bernardino, J.: Edge computing: current trends, research challenges and future directions. Computing 103(5), 993–1023 (2021)

    work page 2021

Show all 55 references
  1. [9]

    Journal of Computing in Civil Engineering 33(3), 04019008 (2019)

    Costin, A., Eastman, C.: Need for interoperability to enable seamless information exchanges in smart and sustainable urban systems. Journal of Computing in Civil Engineering 33(3), 04019008 (2019)

    2019

  2. [10]

    Eclipse Foundation: Eclipse Paho C Client Library (2009), available at https://github.com/eclipse/paho.mqtt.c

    2009

  3. [11]

    In: International Conference on Edge Com- puting (EDGE)

    Giang, N.K., Lea, R., Blackstock, M., Leung, V.C.: Fog at the edge: Experiences building an edge computing platform. In: International Conference on Edge Com- puting (EDGE). pp. 9–16. IEEE (2018)

    2018

  4. [12]

    IEEE Access 11, 42546–42577 (2023)

    Gomez, D.L., Montoya, G.A., Lozano-Garzon, C., Donoso, Y.: Strategies for as- suring low latency, scalability and interoperability in edge computing and TSN networks for critical IIoT services. IEEE Access 11, 42546–42577 (2023)

    2023

  5. [13]

    Journal of Industrial information integra- tion 9, 14–23 (2018)

    G¨ urd¨ ur, D., Asplund, F.: A systematic review to merge discourses: Interoperability, integration and cyber-physical systems. Journal of Industrial information integra- tion 9, 14–23 (2018)

    2018

  6. [14]

    In: Fourth Workshop on Next Generation Real-Time Embedded Systems (NG-RES 2023)

    Jellum, E.R., Lin, S., Donovan, P., Soyer, E., Shakir, F., Bryne, T., Orlandic, M., Lohstroh, M., Lee, E.A.: Beyond the threaded programming model on real-time operating systems. In: Fourth Workshop on Next Generation Real-Time Embedded Systems (NG-RES 2023). Schloss Dagstuhl-...

    2023

  7. [15]

    In: Proceedings of the 1st International Workshop on Middleware for the Computing Continuum

    Jo, Y., Cho, Y., Kim, H.: Secure and lightweight access control for highly de- centralized and distributed file systems. In: Proceedings of the 1st International Workshop on Middleware for the Computing Continuum. pp. 1–6 (2023)

    2023

  8. [16]

    In: 2nd International Conference on Edge Computing and Applications (ICECAA)

    Kannan, B.M., Solainayagi, P., Azath, H., Murugan, S., Srinivasan, C.: Secure communication in IoT-enabled embedded systems for military applications using encryption. In: 2nd International Conference on Edge Computing and Applications (ICECAA). pp. 1385–1389. IEEE (2023) 22 D...

    2023

  9. [17]

    SoftwareX 22, 101390 (May 2023)

    Kim, D., Jo, Y., Kim, T., Kim, H.: SST v1.0.0 with C API: Pluggable se- curity solution for the Internet of Things. SoftwareX 22, 101390 (May 2023). https://doi.org/10.1016/j.softx.2023.101390

    2023

  10. [18]

    In: Proceedings of the 21st ACM Conference on Embedded Networked Sensor Systems

    Kim, D., Kim, H.: Poster abstract: Securing edge-based real-time IoT systems. In: Proceedings of the 21st ACM Conference on Embedded Networked Sensor Systems. p. 544–545. SenSys ’23 (2024). https://doi.org/10.1145/3625687.3628408

    2024

  11. [19]

    In: 2023 Forum on Specification & Design Languages (FDL)

    Kim, H.: Secure programming platform for edge-based IoT: Wild-and-crazy-idea paper. In: 2023 Forum on Specification & Design Languages (FDL). pp. 1–4. IEEE (2023)

    2023

  12. [20]

    ACM Trans

    Kim, H., Kang, E., Broman, D., Lee, E.A.: Resilient authentication and authoriza- tion for the Internet of Things (IoT) using edge computing. ACM Trans. Internet Things 1(1) (mar 2020). https://doi.org/10.1145/3375837

    2020 doi

  13. [21]

    In: The 2nd ACM/IEEE International Conference on Internet-of-Things Design and Implementation

    Kim, H., Kang, E., Lee, E.A., Broman, D.: A toolkit for construction of autho- rization service infrastructure for the Internet of Things. In: The 2nd ACM/IEEE International Conference on Internet-of-Things Design and Implementation. pp. 147–158. Pittsburgh, PA (Apr 2017)

    2017

  14. [22]

    In: The 4th IEEE International Conference on Future Internet of Things and Cloud (FiCloud)

    Kim, H., Wasicek, A., Mehne, B., Lee, E.A.: A secure network architecture for the Internet of Things based on local authorization entities. In: The 4th IEEE International Conference on Future Internet of Things and Cloud (FiCloud). p. 114–122. Vienna, Austria (Aug 2016)

    2016

  15. [23]

    In: Proceedings of the 36th Annual ACM Symposium on Applied Computing

    Koo, J., Kim, Y.G.: Interoperability requirements for a smart city. In: Proceedings of the 36th Annual ACM Symposium on Applied Computing. pp. 690–698 (2021)

    2021

  16. [24]

    IEEE Transactions on Communications 70(1), 500–513 (2021)

    Lai, X., Fan, L., Lei, X., Deng, Y., Karagiannidis, G.K., Nallanathan, A.: Secure mobile edge computing networks in the presence of multiple eavesdroppers. IEEE Transactions on Communications 70(1), 500–513 (2021)

    2021

  17. [25]

    IEEE Communications Surveys & Tutorials 23(2), 1020–1047 (2021)

    Lee, E., Seo, Y.D., Oh, S.R., Kim, Y.G.: A survey on standards for interoperability and security in the internet of things. IEEE Communications Surveys & Tutorials 23(2), 1020–1047 (2021)

    2021

  18. [26]

    IEEE Transactions on Computers 71(10), 2408–2422 (2021)

    Li, B., Dong, W.: Edge-centric programming for IoT applications with automatic code partitioning. IEEE Transactions on Computers 71(10), 2408–2422 (2021)

    2021

  19. [27]

    Journal of Open Source Software 2(13), 265 (2017)

    Light, R.A.: Mosquitto: server and client implementation of the MQTT protocol. Journal of Open Source Software 2(13), 265 (2017)

    2017

  20. [28]

    Journal of Network and Computer Appli- cations 169, 102781 (2020)

    Lin, H., Zeadally, S., Chen, Z., Labiod, H., Wang, L.: A survey on computation offloading modeling for edge computing. Journal of Network and Computer Appli- cations 169, 102781 (2020)

    2020

  21. [29]

    The Linux Foundation: Zephyr RTOS (2016), https://www.zephyrproject.org/

    2016

  22. [30]

    ACM Transactions on Embedded Computing Systems (TECS) 20(4), 1–27 (2021)

    Lohstroh, M., Menard, C., Bateni, S., Lee, E.A.: Toward a lingua franca for deter- ministic concurrent systems. ACM Transactions on Embedded Computing Systems (TECS) 20(4), 1–27 (2021)

    2021

  23. [31]

    In: 2020 Forum for Specification and Design Languages (FDL)

    Lohstroh, M., Menard, C., Schulz-Rosengarten, A., Weber, M., Castrillon, J., Lee, E.A.: A language for deterministic coordination across multiple timelines. In: 2020 Forum for Specification and Design Languages (FDL). pp. 1–8. IEEE (2020)

    2020

  24. [32]

    In: Cyber Physical Systems

    Lohstroh, M., Romeo, ´I.´I., Goens, A., Derler, P., Castrillon, J., Lee, E.A., Sangiovanni-Vincentelli, A.: Reactors: A deterministic model for composable re- active systems. In: Cyber Physical Systems. Model-Based Design: 9th Interna- tional Workshop, CyPhy 2019, and 15th Int...

    2020

  25. [33]

    In: A Case Study of API Design for Interoperability and Security of the IoT 23 Leveraging Applications of Formal Methods, Verification and Validation

    Margaria, T., Chaudhary, H.A.A., Guevara, I., Ryan, S., Schieweck, A.: The inter- operability challenge: Building a model-driven digital thread platform for CPS. In: A Case Study of API Design for Interoperability and Security of the IoT 23 Leveraging Applications of Formal Me...

  26. [34]

    IEEE Transactions on software Engineering (4), 308–320 (1976)

    McCabe, T.J.: A complexity measure. IEEE Transactions on software Engineering (4), 308–320 (1976)

    1976

  27. [35]

    Future Generation Computer Systems 106, 67–76 (2020)

    Ning, H., Li, Y., Shi, F., Yang, L.T.: Heterogeneous edge computing open platforms and tools for Internet of things. Future Generation Computer Systems 106, 67–76 (2020)

    2020

  28. [36]

    Mobile networks and applications 24, 796–809 (2019)

    Noura, M., Atiquzzaman, M., Gaedke, M.: Interoperability in Internet of Things: Taxonomies and open challenges. Mobile networks and applications 24, 796–809 (2019)

    2019

  29. [37]

    OMG Specification formal/2015-04-10, Object Management Group (OMG) (2015), https://www.omg.org/spec/DDS/1.4/PDF

    Object Management Group (OMG): Data Distribution Service (DDS) Version 1.4. OMG Specification formal/2015-04-10, Object Management Group (OMG) (2015), https://www.omg.org/spec/DDS/1.4/PDF

    2015

  30. [38]

    In: Proceedings of the 37th ACM/SIGAPP Symposium on Applied Computing

    Oh, S.R., Koo, J., Kim, Y.G.: Security interoperability in heterogeneous IoT plat- forms: threat model of the interoperable OAuth 2.0 framework. In: Proceedings of the 37th ACM/SIGAPP Symposium on Applied Computing. pp. 22–31 (2022)

    2022

  31. [39]

    OPC Foundation: The OPC Unified Architecture (UA) (2008), available at https://opcfoundation.org/about/opc-technologies/opc-ua/

    2008

  32. [40]

    In: International Symposium on Industrial Electronics (ISIE)

    Pereira, P.H.M., Cainelli, G., Pereira, C.E., Costa, J.P.J.D., Freitas, E.P.D.: An interoperability middleware for IIoT. In: International Symposium on Industrial Electronics (ISIE). pp. 1–6. IEEE (2023)

    2023

  33. [41]

    In: 2020 IEEE International Conference on Consumer Electronics (ICCE)

    Quadir, M.S.E., Chandy, J.A.: Embedded systems authentication and encryption using strong PUF modeling. In: 2020 IEEE International Conference on Consumer Electronics (ICCE). pp. 1–6. IEEE (2020)

    2020

  34. [42]

    In: ICRA workshop on open source software

    Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T., Leibs, J., Wheeler, R., Ng, A.Y., et al.: ROS: an open-source robot operating system. In: ICRA workshop on open source software. vol. 3, p. 5. Kobe, Japan (2009)

    2009

  35. [43]

    Transactions on Emerging Telecommu- nications Technologies 32(8), e4166 (2021)

    Rana, B., Singh, Y., Singh, P.K.: A systematic survey on internet of things: Energy efficiency and interoperability perspective. Transactions on Emerging Telecommu- nications Technologies 32(8), e4166 (2021)

    2021

  36. [44]

    Raspberry Pi Foundation: RP2040 Microcontroller Datasheet (2021), https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdft

    2021

  37. [45]

    ACM Transactions on Computer Systems (TOCS) 2(4), 277–288 (1984)

    Saltzer, J.H., Reed, D.P., Clark, D.D.: End-to-end arguments in system design. ACM Transactions on Computer Systems (TOCS) 2(4), 277–288 (1984)

    1984

  38. [46]

    In: International symposium in sensing and instrumentation in IoT Era (ISSI)

    Shapsough, S., Aloul, F., Zualkernan, I.A.: Securing low-resource edge devices for IoT systems. In: International symposium in sensing and instrumentation in IoT Era (ISSI). pp. 1–4. IEEE (2018)

    2018

  39. [47]

    In: 2018 IEEE 6th International Conference on Future Internet of Things and Cloud (FiCloud)

    Sigwele, T., Hu, Y.F., Ali, M., Hou, J., Susanto, M., Fitriawan, H.: An intelligent edge computing based semantic gateway for healthcare systems interoperability and collaboration. In: 2018 IEEE 6th International Conference on Future Internet of Things and Cloud (FiCloud). pp....

    2018

  40. [48]

    In: International Confer- ence on Practical Applications of Agents and Multi-Agent Systems

    S ´anchez, S.M., Lecumberri, F., Sati, V., Arora, A., Shoeibi, N., Rodr ´ıguez, S., Rodr´ıguez, J.M.C.: Edge computing driven smart personal protective system de- ployed on NVIDIA Jetson and integrated with ROS. In: International Confer- ence on Practical Applications of Agent...

    2020

  41. [49]

    In: 2019 IEEE European Sym- posium on Security and Privacy Workshops (EuroS&PW)

    Tedeschi, P., Sciancalepore, S.: Edge and fog computing in critical infrastructures: Analysis, security threats, and research challenges. In: 2019 IEEE European Sym- posium on Security and Privacy Workshops (EuroS&PW). pp. 1–10. IEEE (2019)

    2019

  42. [50]

    Wiley (2008) 24 D

    van Vliet, H.: Software Engineering: Principles and Practice. Wiley (2008) 24 D. Kim et al

    2008

  43. [51]

    Proceedings of the IEEE 107(8), 1608–1631 (2019)

    Xiao, Y., Jia, Y., Liu, C., Cheng, X., Yu, J., Lv, W.: Edge computing security: State of the art and challenges. Proceedings of the IEEE 107(8), 1608–1631 (2019)

    2019

  44. [52]

    IEEE access 6, 6900–6919 (2017)

    Yu, W., Liang, F., He, X., Hatcher, W.G., Lu, C., Lin, J., Yang, X.: A survey on the edge computing for the Internet of Things. IEEE access 6, 6900–6919 (2017)

    2017

  45. [53]

    In: 2020 International Conference on Big Data, Artificial Intelligence and Internet of Things Engineering (ICBAIE)

    Zeyu, H., Geming, X., Zhaohang, W., Sen, Y.: Survey on edge computing security. In: 2020 International Conference on Big Data, Artificial Intelligence and Internet of Things Engineering (ICBAIE). pp. 96–105. IEEE (2020)

    2020

  46. [54]

    In: 2022 Seventh International Conference on Fog and Mobile Edge Computing (FMEC)

    Zhang, J., Keramat, F., Yu, X., Hern´ andez, D.M., Queralta, J.P., Westerlund, T.: Distributed robotic systems in the edge-cloud continuum with ROS 2: a review on novel architectures and technology readiness. In: 2022 Seventh International Conference on Fog and Mobile Edge Com...

    2022

  47. [2021]

    Lecture Notes in Computer Science. pp. 393–413. Springer (2021)

    2021

Pith tools

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