Model-Based Systems Engineering Framework for SysML-Driven Design of Autonomous UAVs

Bharath Kumar Suryadevara; Deekshitha Angadi; Mohamed Samshad; Narsimlu Kemsaram; Naveena Budda; Vikas Agarwal

REVIEW 3 major objections 3 minor 20 references

Model-Based Systems Engineering Framework for SysML-Driven Design of Autonomous UAVs

T0 review · 3 major / 3 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 A design-phase framework claims that a four-layer SysML model can connect UAV stakeholder requirements, behavior, and logical architecture to ROS 2 nodes, topics, services, and actions in one traceable chain.

desk verdict A coherent but unvalidated design workflow; the traceability promise is manually maintained and asserted rather than demonstrated. read the letter →

arxiv 2608.09547 v1 pith:YECKZFGM submitted 2026-08-10 cs.RO

Deekshitha Angadi , Naveena Budda , Vikas Agarwal , Mohamed Samshad , Bharath Kumar Suryadevara , Narsimlu Kemsaram This is my paper · ORCID

classification cs.RO

keywords model-basedsystemsengineeringSysMLv2autonomousUAVROS2systemarchitecturetraceabilityverificationplanning

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 paper tries to establish that a four-layer, SysML-based design workflow can serve as a formal backbone for autonomous UAV development, connecting stakeholder requirements, functional decomposition, logical architecture, and physical/software allocation before any code or simulation exists. Under the framework, SysML blocks, flow ports, connectors, and behaviors translate into ROS 2 nodes, topics, services, and actions, so planned software interfaces can be traced back to requirements and system functions. A sympathetic reader would care because the framework promises to move UAV development away from documents that drift apart and toward one model that already ties requirements to verification cases. The paper presents the design as a baseline for later Gazebo simulation, hardware-in-the-loop validation, and flight testing, and is explicit that the SysML-to-ROS 2 mapping is manually maintained.

What carries the argument

The load-bearing mechanism is the SysML-to-ROS 2 mapping rule set, defined in one phrase as blocks become nodes, flow ports and connectors become topics, request-response interactions become services, and goal-oriented behaviors become actions. These four rules carry the argument by converting the SysML logical architecture into a communication architecture, making every planned ROS 2 interface traceable to a model element. The supporting model artifacts are the requirement diagrams, activity and sequence diagrams, block definition and internal block diagrams, state machine diagrams, and parametric diagrams that produce the elements the mapping operates on. The framework also uses SysML traceability relationships—requirement, allocation, satisfaction, and verify links—to connect stakeholder needs to functions, elements, interfaces, and future test cases.

What would settle it

Take the six-subsystem SysML model and the proposed ROS 2 architecture, then list every flow port, connector, state transition, and requirement link against every topic, service, and action. A completeness check would fail if any connector has no mapped ROS 2 interface or any ROS 2 interface has no upstream SysML source; because the mapping is manual, repeating the check after one design change should reveal drift in the traceability links.

Watch

Extended reading notes

Core claim

The paper's central claim is that a connected SysML v2 model can give an autonomous UAV project a single traceable chain running from stakeholder needs to planned ROS 2 interfaces. The UAV is decomposed into six logical subsystems—flight control, navigation and localization, perception and sensing, communication, mission management, and power management—and each becomes a corresponding ROS 2 node. Continuous flows such as navigation state, obstacle data, telemetry, and battery status become topics; discrete commands such as mission upload and health queries become services; long-running missions such as waypoint navigation, mission execution, and return-to-home become actions. Mission states (Idle, Pre-flight Check, Take-off, Navigate, Hover, Obstacle Avoidance, Return-to-Home, Landing, Emergency) and parametric constraints (navigation accuracy, communication latency, endurance, detection range) are captured in the same model, and requirement-to-test relationships are defined before implementation. If the framework works as described, the design model itself becomes the place where ambiguity, missing interfaces, and untestable requirements are caught.

Load-bearing premise

The promised traceability depends on a manually maintained SysML v2 model staying complete and correct through design iterations; the paper states that the SysML-to-ROS 2 mapping is maintained by hand, with no automated synchronization or consistency checking.

Editorial extensions

If this is right

A requirement change can be traced forward to the affected subsystems, ROS 2 nodes, topics, services, actions, and verification cases before implementation begins.
Verification planning is moved into design: each requirement is tied to a future Gazebo test, hardware-in-the-loop test, or field test, so test gaps become visible early.
Mission-level behaviors and safety responses are specified as state transitions before software coding, giving the future ROS 2 mission manager a defined contract.
The same four-layer structure and mapping rules can be reused to start other UAV or cyber-physical system designs without redoing the SysML-to-ROS 2 bridge.
The design baseline is reproducible: given the same SysML diagrams and mapping rules, different teams should produce the same planned ROS 2 interface set.

Reading between the lines

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

A natural next test is to auto-generate ROS 2 interface skeletons or a machine-readable interface specification directly from the SysML model, which would make the manual-maintenance risk measurable; the paper only lists this as future work.
The mapping could be stress-tested by making a single change, such as adding a topic or splitting a subsystem, and checking how many traceability links require manual updates; the paper's claims do not quantify this effort.
The same design discipline could be extended to multi-UAV cooperative missions, where interface drift between vehicles would be harder to catch by hand, an extension the paper mentions but does not develop.
Until the planned Gazebo and hardware-in-the-loop experiments run, the claimed reduction in ambiguity remains a methodological proposal; measuring it would require comparing interface drift and defect-discovery time against a document-centric baseline.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

The paper is a clearly written design-phase framework for connecting SysML v2 models to a ROS 2 architecture for autonomous UAVs. The four-layer decomposition (requirements, functional, logical, physical/software allocation) and the six-subsystem example are useful organizing devices. The paper also does honest work: it cites MeROS and ROS2ML as the source of the block-to-node, port-to-topic, request-to-service, behavior-to-action mapping, and it explicitly states that the mapping is currently manual and that automated transformation and consistency checking are future work. There are no fitted parameters, no invented entities, and no circular argument. For a practitioner wanting a starting template for MBSE-to-ROS2 on UAVs, this is a reasonable read. The soft spots are real and they sit exactly where the stress-test note puts them. The traceability claim — the paper's main selling point — depends on mapping rules that are prose-level and ambiguous (what counts as a "continuous data stream" versus a discrete interaction? how do item types become message types?) and on links that are hand-maintained. Section 6 admits there is no automated synchronization, so the "traceable bridge" is an assertion about a process, not a demonstrated property of the delivered model. The benefit claims (reduced ambiguity, improved interface consistency) are plausible but unmeasured: no simulation, no hardware, no baseline comparison, no released SysML model files for others to inspect. The abstract and conclusion phrase these as accomplished results, which overstates what the paper actually shows. That said, the authors are transparent about the limitations, and the framework itself is internally coherent. The weakness is that the central guarantee is not enforced, not that the authors are hiding it. This is a solid workshop-level or conference design paper, not a fraudulent or confused one. A serious referee would have concrete, addressable requests: provide a metamodel or a more precise mapping table with clear classification criteria, release the SysML v2 artifacts, add a comparison table with MeROS and ROS2ML, and soften the conclusions to match the design-phase evidence. My take: send it to peer review rather than desk-reject. It deserves referee time, but it needs revision before acceptance. The reader's CONDITIONAL verdict and the stress-test concern are both accurate; I would not push back on either. I would not cite it in my own work in the next year, but I might bring it to a reading group as an example of how far an unvalidated design workflow can go.

Referee Report

3 major / 3 minor

Summary. This paper proposes a design-phase MBSE framework for autonomous UAV development that links stakeholder requirements, functional decomposition, logical architecture, and physical/software allocation. The framework is expressed through SysML v2 artifacts (requirement, activity, block definition, internal block, state machine, and parametric diagrams) and defines a mapping from SysML elements to ROS 2 nodes, topics, services, and actions. The mapping is described in §5.1 as four rules, and the resulting ROS 2 node architecture is sketched in §5.2. The paper is explicitly design-oriented: it does not present simulation, hardware, or flight results, and §6 states that the mapping is manually maintained with future work on model transformation and consistency checking. The central claim is that the framework establishes a traceable design baseline that reduces early-stage ambiguity and improves interface consistency.

Significance. If the mapping rules were made precise and machine-checkable, the framework could provide a useful bridge between SysML-based systems engineering and ROS 2 implementation for UAVs. The paper is honest about its design-phase scope and explicitly references existing metamodels (MeROS, ROS2ML) while differentiating its four-layer UAV-oriented focus. It also uses SysML v2 rather than the older SysML 1.x, which is a contemporary choice. However, the claimed benefits—reduced ambiguity, interface consistency, and traceability—are not measured or demonstrated. The paper contains no executable transformation, no consistency-checking mechanism, no concrete worked example that traces a requirement through the mapping to a ROS 2 interface, and no baseline comparison. Its contribution is thus a plausible but unvalidated design proposal.

major comments (3)

[§5.1] The four mapping rules are underspecified. Rule 2 says flow ports and connectors are mapped to topics 'when they represent continuous data streams,' and Rule 3 maps discrete command-and-query interactions to services, but no operational criterion is given for distinguishing continuous from discrete. A single interface, such as the obstacle information flow from the Perception and Sensing System to the Mission Management System, could plausibly be modeled both as a continuous data stream and as a request-response query depending on the modeler's choice. The rules also do not map SysML item types to ROS 2 message types, nor do they include a constraint ensuring that every interface is classified exactly once. Without these details, the claim that the mapping 'systematically' bridges SysML and ROS 2 is not established; the mapping remains a set of prose heuristics.
[§6] The paper explicitly concedes that the mapping is 'design-oriented and manually maintained within the modeling workflow' and that there is no automatic synchronization or consistency checking between the SysML v2 model and the ROS 2 implementation. Because the traceability links are human-maintained artifacts, the conclusion that the framework 'provides a traceable bridge' is an assertion about a process that is not enforced. This is a load-bearing weakness: the paper's central benefit claim is that the framework reduces ambiguity and interface inconsistency, but ambiguous mapping rules combined with hand-maintained links are exactly the failure mode the paper attributes to document-centric workflows. The authors should either provide a machine-checkable transformation or profile (e.g., built on MeROS/ROS2ML concepts), or substantially weaken the claim to 'informal mapping guidance' and show how traceability is maintained in practice.
[§4.1 and §5.2] There is no concrete demonstration of the proposed framework on a specific interface or scenario. Section 4.1 introduces three scenarios (waypoint navigation, infrastructure inspection, sense-and-avoid), and §5.2 lists six nodes and several topics, services, and actions, but the paper never walks through even one complete trace from a stakeholder requirement, through the SysML flow port and connector, to a specific ROS 2 topic type and a verification relationship. As a result, the claimed reduction of ambiguity and improvement of interface consistency are unmeasured. A single worked example—for instance, tracing the obstacle-detection requirement to the pss_node-to-mms_node topic—would demonstrate whether the mapping rules are unambiguous and complete in practice.

minor comments (3)

[Title and abstract] The title in the provided text reads 'Autonomous UA Vs' due to a line-break artifact; the authors should ensure the final PDF renders as 'Autonomous UAVs.'
[§5.1] The mapping rules are introduced as 'four main rules,' but the supporting text does not provide a table or diagram that shows the correspondence between specific SysML v2 element types (e.g., part definition, part usage, port, connection, item flow) and ROS 2 concepts. A tabular summary would improve clarity and make it easier for readers to assess the completeness of the mapping.
[§4.5] The verification planning model is described at a high level; the text states that SysML verify relationships link requirements to future test cases, but no example of a concrete verify relationship or its target is given. Since verification planning is one of the four contributions, an example requirement-to-test trace would strengthen the presentation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's framework is a design proposal with no fitted parameters or formal derivation, self-citations are background only, and the acknowledged manual mapping is a limitation, not a circular step.

full rationale

The paper contains no equations, no fitted parameters, and no quantitative prediction whose output is equivalent to its input by construction. Its central content is a four-layer MBSE workflow and a set of prose-level mapping rules from SysML elements to ROS 2 concepts (blocks to nodes, flow ports/connectors to topics, request-response to services, goal-oriented behaviors to actions). These mapping rules are asserted as design conventions, not derived from any prior result, so they cannot be circular in the sense of 'prediction equals fit.' The author self-citations (refs. 10, 11, 14) provide background on prior SysML-based design work and on an onboard visual tracking system; none of them is load-bearing for the framework's structure or for the SysML-to-ROS 2 mapping. Section 5.1 states that the mapping is 'informed by previous ROS-oriented SysML metamodels and profiles, particularly MeROS and ROS2ML [16, 17],' but those are external works by other authors, and the paper explicitly reformulates the mapping for SysML v2 and UAV verification planning. The clearest potential concern is the limitation disclosed in Section 6: the mapping is 'design-oriented and manually maintained within the modeling workflow,' with no automated synchronization or consistency checking. That is a correctness and maturity risk for the traceability claim, but it is not circularity; the paper openly labels this as future work and does not pretend the manual mapping is a derived guarantee. The conclusion largely restates the framework's own definitions and intended benefits, but restatement of a proposed method is not circular evidence. Overall, no circular step can be exhibited from the paper's own text, so the appropriate finding is no significant circularity (score 0).

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

The framework is a modeling methodology, so it introduces no fitted constants and no new physical entities. It depends on three unverified assumptions: semantic soundness of the mapping rules, reliability of manually maintained links, and the effectiveness of design-time modeling itself. The paper's own limitation section confirms the second assumption is currently unenforced.

assumptions (3)

ad hoc to paper The SysML v2 mapping rules preserve the meaning of modeled flows and behaviors when translated into ROS 2 nodes, topics, services, and actions.
Section 5.1 states four mapping rules without formal semantics or proof that traceability is preserved; the framework's central promise depends on this correspondence.
domain assumption Manually maintained traceability and allocation links remain complete and consistent through design iterations.
Section 6 acknowledges the mapping is manually maintained within the modeling workflow and lacks automated synchronization; if links drift, the claimed traceable baseline degrades.
domain assumption A design-phase SysML model, before simulation or implementation, reduces ambiguity and interface inconsistencies compared with document-centric workflows.
Sections 1 and 7 assert the benefit, but no controlled evaluation or baseline is provided; this is the general MBSE promise borrowed from cited references.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Model-Based Systems Engineering Framework for SysML-Driven Design of Autonomous UAVs." pith.science (2026). https://pith.science/paper/YECKZFGM

@misc{pith2026260809547,
  author       = {Pith},
  title        = {Pith review of: Model-Based Systems Engineering Framework for SysML-Driven Design of Autonomous UAVs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YECKZFGM}},
  note         = {Machine review of arXiv:2608.09547}
}

read the original abstract

Autonomous Unmanned Aerial Vehicles (UAVs) are complex cyber-physical systems that require the coordinated integration of flight control, navigation, perception, communication, power management, and mission-level decision-making under safety, timing, and reliability constraints. However, many autonomous UAV development workflows still rely on document-centric requirements, separated architectural descriptions, and software implementation artifacts, which can lead to ambiguity, interface inconsistencies, and weak traceability during early design. This paper presents a Model-Based Systems Engineering (MBSE) design framework for the SysML-driven development of autonomous UAVs. The proposed framework uses the Systems Modeling Language (SysML) as a formal design backbone to structure UAV development across four connected layers: stakeholder requirements, functional decomposition, logical architecture, and physical/software allocation. SysML requirement diagrams, activity diagrams, block definition diagrams, internal block diagrams, state machine diagrams, and parametric diagrams are used to capture the functional, structural, behavioral, interface, and performance aspects of the UAV system. The logical architecture is then systematically mapped to a Robot Operating System 2 (ROS 2) software architecture by relating SysML blocks to ROS 2 nodes, flow ports and connectors to topics, request-response interactions to services, and goal-oriented behaviors to actions. The framework is illustrated at the design level using representative autonomous UAV mission scenarios, including autonomous take-off, waypoint navigation, hover stabilization, obstacle avoidance, return-to-home, and emergency handling. The resulting model supports requirement allocation, interface definition, subsystem responsibility assignment, and verification planning before simulation or physical deployment.

Figures

Figures reproduced from arXiv: 2608.09547 by the authors.

**Figure 1.** Proposed MBSE-SysML-ROS 2 design framework for autonomous UAV development. The framework connects stakeholder requirements, functional decomposition, logical architecture, and physical/software allocation to establish a traceable design baseline before simulation and physical deployment. Navigation and Localization System, Perception and Sensing System, Communication System, Mission Management System, and Power Ma… view at source ↗

**Figure 2.** Mission state machine for autonomous UAV operation. The design-level state machine defines the main UAV operating modes, including Idle, Pre-flight Check, Takeoff, Navigate, Hover, Obstacle Avoidance, Return-to-Home, Landing, and Emergency. The transitions capture nominal mission progression and safety-related recovery paths triggered by obstacle detection, mission completion, low battery, link loss, or critical fa… view at source ↗

**Figure 3.** SysML logical architecture of the autonomous UAV system. The design decomposes the UAV into six major subsystems: Flight Control System, Navigation and Localization System, Perception and Sensing System, Communication System, Mission Management System, and Power Management System. The main data and command flows provide the basis for later ROS 2 topic, service, and action mapping. quirements are linked to hardware-… view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: SysML-to-ROS 2 software architecture mapping. SysML subsystem blocks are allocated to corresponding ROS 2 nodes, interface flows are mapped to topics, command-and-query interactions are mapped to services, and long-running mission behaviors are mapped to actions. This …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 12 canonical work pages

[1]

Wiley, Hoboken (2023)

INCOSE: Systems Engineering Handbook: A Guide for System Life Cycle Pro- cesses and Activities, 5th edn. Wiley, Hoboken (2023)

work page 2023
[2]

International Organization for Standardization, Geneva (2015)

ISO/IEC/IEEE: ISO/IEC/IEEE 15288: Systems and Software Engineering— System Life Cycle Processes. International Organization for Standardization, Geneva (2015)

work page 2015
[3]

Systems Engineering21(3), 172–190 (2018)

Madni, A.M., Sievers, M.: Model-based systems engineering: Motivation, current status, and research opportunities. Systems Engineering21(3), 172–190 (2018). https://doi.org/10.1002/sys.21438

doi:10.1002/sys.21438 2018
[4]

Morgan Kaufmann, Waltham (2014)

Friedenthal, S., Moore, A., Steiner, R.: A Practical Guide to SysML: The Systems Modeling Language, 3rd edn. Morgan Kaufmann, Waltham (2014)

work page 2014
[5]

Addison-Wesley, Boston (2013)

Delligatti, L.: SysML Distilled: A Brief Guide to the Systems Modeling Language. Addison-Wesley, Boston (2013)

work page 2013
[6]

OMG formal specification, formal/2019-11-01 (2019)

Object Management Group: OMG Systems Modeling Language, Version 1.6. OMG formal specification, formal/2019-11-01 (2019)

work page 2019
[7]

Science Robotics7(66), eabm6074 (2022)

Macenski, S., Foote, T., Gerkey, B., Lalancette, C., Woodall, W.: Robot Operat- ing System 2: Design, architecture, and uses in the wild. Science Robotics7(66), eabm6074 (2022). https://doi.org/10.1126/scirobotics.abm6074

doi:10.1126/scirobotics.abm6074 2022
[8]

In: Pro- ceedings of the 2016 ACM 13th International Conference on Embedded Software (EMSOFT), 1–10 (2016)

Maruyama, Y., Kato, S., Azumi, T.: Exploring the performance of ROS2. In: Pro- ceedings of the 2016 ACM 13th International Conference on Embedded Software (EMSOFT), 1–10 (2016). https://doi.org/10.1145/2968478.2968502

work page arXiv 2016

Show all 20 references

[9]

Procedia Manufacturing38, 349–357 (2019)

Erős, E., Dahl, M., Bengtsson, K., Hanna, A., Falkman, P.: A ROS2 based communication architecture for control in collaborative and intel- ligent automation systems. Procedia Manufacturing38, 349–357 (2019). https://doi.org/10.1016/j.promfg.2020.01.045 14 D. Angadi et al

2019 doi
[10]

In: 2021 IEEE 2nd International Informatics and Software Engineering Conference (IISEC), 1–6 (2021)

Kemsaram, N., Das, A., Dubbelman, G.: Model-based systems engineering to de- sign an onboard surround vision system for cooperative automated vehicles. In: 2021 IEEE 2nd International Informatics and Software Engineering Conference (IISEC), 1–6 (2021). https://doi.org/10.1109/...

2021
[11]

In: 2021 IEEE International Conference on Electrical, Computer and Energy Technologies (ICECET), 1–8, (2021)

Kemsaram, N., Das, A., Dubbelman, G.: A SysML-based design and de- velopment of stereo vision system with pose and velocity estimation for cooperative automated vehicles. In: 2021 IEEE International Conference on Electrical, Computer and Energy Technologies (ICECET), 1–8, (202...

2021
[12]

Systems10(6), 264 (2022)

Hossain, N.U.I., Lutfi, M., Ahmed, I., Akundi, A., Cobb, D.: Modeling and anal- ysis of unmanned aerial vehicle system leveraging Systems Modeling Language (SysML). Systems10(6), 264 (2022). https://doi.org/10.3390/systems10060264

2022 doi
[13]

In: 2021 IEEE International Conference on Unmanned Systems (ICUS), 767–772 (2021)

Wang, Y., Sun, Q., Wang, M., Zhang, Y.: The requirement traceable modeling method and application of UAV command system-of-systems based on SysML. In: 2021 IEEE International Conference on Unmanned Systems (ICUS), 767–772 (2021). https://doi.org/10.1109/ICUS52573.2021.9641259

2021
[14]

Kemsaram, N., Thatiparti, V. R. K., Guntupalli, D. R., Kuvvarapu, A.: Design and development of an on-board autonomous visual track- ing system for unmanned aerial vehicles. Aviation,21(3), 83–91, (2017). https://doi.org/10.3846/16487788.2017.1378265

2017
[15]

In: 2022 IEEE International Systems Conference (SysCon), 1–8 (2022)

Aloui, K., Hammadi, M., Guizani, A., Haddar, M., Soriano, T.: A new SysML model for UAV swarm modeling: UavSwarmML. In: 2022 IEEE International Systems Conference (SysCon), 1–8 (2022). https://doi.org/10.1109/SysCon53536.2022.9773922

2022
[16]

IEEE Access11, 82802–82815 (2023)

Winiarski, T.: MeROS: SysML-based metamodel for ROS-based systems. IEEE Access11, 82802–82815 (2023). https://doi.org/10.1109/ACCESS.2023.3301727

2023
[17]

Proceedings of the Institution of Mechanical Engineers, Part C: Journal of Mechanical Engineering Science237(16), 3650–3664 (2023)

Guizani, A., Aloui, K., Hammadi, M., Soriano, T., Haddar, M.: A new SysML profile for autonomous mobile robots development: ROS2ML. Proceedings of the Institution of Mechanical Engineers, Part C: Journal of Mechanical Engineering Science237(16), 3650–3664 (2023). https://doi.o...

2023 doi
[18]

International Organization for Standardization, Geneva (2018)

ISO/IEC/IEEE: ISO/IEC/IEEE 29148:2018 Systems and Software Engineering— Life Cycle Processes—Requirements Engineering. International Organization for Standardization, Geneva (2018)

2018
[19]

In: Proceedings of the IEEE/RSJ International Confer- ence on Intelligent Robots and Systems, pp

Koenig, N., Howard, A.: Design and use paradigms for Gazebo, an open-source multi-robot simulator. In: Proceedings of the IEEE/RSJ International Confer- ence on Intelligent Robots and Systems, pp. 2149–2154. IEEE, Sendai (2004). https://doi.org/10.1109/IROS.2004.1389727

2004 arXiv
[20]

In: Proceedings of the IEEE International Conference on Robotics and Automation, pp

Meier, L., Honegger, D., Pollefeys, M.: PX4: A node-based multithreaded open- source robotics framework for deeply embedded platforms. In: Proceedings of the IEEE International Conference on Robotics and Automation, pp. 6235–6240. IEEE, Seattle (2015). https://doi.org/10.1109/...

2015

Pith tools

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

[1] [1]

Wiley, Hoboken (2023)

INCOSE: Systems Engineering Handbook: A Guide for System Life Cycle Pro- cesses and Activities, 5th edn. Wiley, Hoboken (2023)

work page 2023

[2] [2]

International Organization for Standardization, Geneva (2015)

ISO/IEC/IEEE: ISO/IEC/IEEE 15288: Systems and Software Engineering— System Life Cycle Processes. International Organization for Standardization, Geneva (2015)

work page 2015

[3] [3]

Systems Engineering21(3), 172–190 (2018)

Madni, A.M., Sievers, M.: Model-based systems engineering: Motivation, current status, and research opportunities. Systems Engineering21(3), 172–190 (2018). https://doi.org/10.1002/sys.21438

doi:10.1002/sys.21438 2018

[4] [4]

Morgan Kaufmann, Waltham (2014)

Friedenthal, S., Moore, A., Steiner, R.: A Practical Guide to SysML: The Systems Modeling Language, 3rd edn. Morgan Kaufmann, Waltham (2014)

work page 2014

[5] [5]

Addison-Wesley, Boston (2013)

Delligatti, L.: SysML Distilled: A Brief Guide to the Systems Modeling Language. Addison-Wesley, Boston (2013)

work page 2013

[6] [6]

OMG formal specification, formal/2019-11-01 (2019)

Object Management Group: OMG Systems Modeling Language, Version 1.6. OMG formal specification, formal/2019-11-01 (2019)

work page 2019

[7] [7]

Science Robotics7(66), eabm6074 (2022)

Macenski, S., Foote, T., Gerkey, B., Lalancette, C., Woodall, W.: Robot Operat- ing System 2: Design, architecture, and uses in the wild. Science Robotics7(66), eabm6074 (2022). https://doi.org/10.1126/scirobotics.abm6074

doi:10.1126/scirobotics.abm6074 2022

[8] [8]

In: Pro- ceedings of the 2016 ACM 13th International Conference on Embedded Software (EMSOFT), 1–10 (2016)

Maruyama, Y., Kato, S., Azumi, T.: Exploring the performance of ROS2. In: Pro- ceedings of the 2016 ACM 13th International Conference on Embedded Software (EMSOFT), 1–10 (2016). https://doi.org/10.1145/2968478.2968502

work page arXiv 2016