Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- en:safeav:as:refarchitectures [2025/10/17 09:11] – created agrisnik
+++ en:safeav:as:refarchitectures [2025/10/17 09:21] (current) – [MOOS-IvP Architecture for Marine Systems] agrisnik
@@ Line 7: / Line 7: @@
 Robot Operating System (ROS) provides a modular, publish–subscribe communication infrastructure widely adopted in research and industry. Its successor, ROS 2, adds real-time capabilities, security features, and DDS-based communication, making it suitable for production-grade autonomous systems ((Maruyama, Y., Kato, S., & Azumi, T. (2016). Exploring the performance of ROS2. Proceedings of the 13th Embedded Real-Time Systems Workshop (ERTS 2016))).
+<figure ROS 2 Layered Architecture >
+{{ :en:safeav:as:rtu_ch1_figure4.png?400| ROS 2 Layered Architecture}}
+<caption>ROS 2 Layered Architecture (simplified from ROS 2 documentation)</caption>
+</figure>
 The ROS 2 architecture provides several advantages, including component-level independence from the provider, modularity enabling easier development as well as large community and libraries of packages for deployment. ROS 2 is now the backbone for major open-source projects such as Autoware.AI (autonomous driving) and PX4-Autopilot (UAV control).
+===== AUTOSAR Adaptive Platform =====
+In the automotive sector, the AUTOSAR (AUTomotive Open System ARchitecture) standard defines a scalable, service-oriented architecture supporting high-performance applications such as automated driving ((AUTOSAR Consortium. (2023). AUTOSAR Adaptive Platform Specification. AUTOSAR)).
+<figure AUTOSAR Adaptive Platform Overview >
+{{ :en:safeav:as:rtu_ch1_figure5.png?400| AUTOSAR Adaptive Platform Overview}}
+<caption>AUTOSAR Adaptive Platform Overview(simplified)</caption>
+</figure>
+The AUTOSAR Adaptive Platform is conceptually a middleware. AUTOSAR Adaptive Platform provides services to Adaptive Applications beyond those available from the underlying operating system, drivers, and extensions. One of the distinctive features of the AUTOSTAR is its Real-time and safety-critical compliance (ISO 26262) as well as use of SOME/IP and DDS for service-based communication purposes. AUTOSAR is widely implemented in production autonomous vehicles from manufacturers like BMW, Volkswagen, and Toyota ((Broy, M., et al. (2021). Modeling Automotive Software Architectures with AUTOSAR. Springer)).
+===== JAUS – Joint Architecture for Unmanned Systems =====
+The JAUS (Joint Architecture for Unmanned Systems) is a U.S. Department of Defense standard (SAE AS5669A) defining a message-based, modular architecture for interoperability among unmanned systems ((Gavrilets, V., et al. (2010). JAUS message-based architecture for unmanned vehicle interoperability. IEEE Aerospace Conference Proceedings, 1–8)). It is domain-agnostic, supporting aerial, ground, and marine vehicles.
+JAUS defines:
+  * A component-based hierarchy (Subsystem → Node → Component → Service)
+  * Standardised message sets for communication
+  * Cross-domain interoperability
+<figure JAUS Component Hierarchy >
+{{ :en:safeav:as:rtu_ch1_figure6.png?400| JAUS Component Hierarchy}}
+<caption>JAUS Component Hierarchy</caption>
+</figure>
+JAUS remains influential in defence and research projects where multiple unmanned vehicles must coordinate under a unified framework. Due to its straightforward and easy-to-implement architecture, it has been adopted by different systems and domains
+===== MOOS-IvP Architecture for Marine Systems =====
+MOOS (Mission Oriented Operating Suite) combined with IvP (Interval Programming) forms a robust architecture for marine autonomy, developed at MIT and used in NATO and U.S. Navy programs ((Benjamin, M. R., Curcio, J. A., & Leonard, J. J. (2012). MOOS-IvP autonomy software for marine robots. Journal of Field Robotics, 29(6), 821–835)).
+<figure MOOS-IvP Architecture >
+{{ :en:safeav:as:rtu_ch1_figure7.png?400| MOOS-IvP Architecture}}
+<caption>Simplified MOOS-IvP Architecture</caption>
+</figure>
+IvP (Interval Programming) Helm provides decision-making capabilities based on models provided by the developers, while MOOS DB provides access to data and decisions collected by Applications. Client applications (or just Applications are the main functionality, and modularity drives the ability to integrate different functions, logically isolating them and providing access through a common communications space. The communications are enabled using pMOOSBridge middleware.
+All of the mentioned allow an asynchronous behaviour-based response to a changing environment and higher flexibility, easier maintainability and to some extent future-proof solutions.
+===== Comparative Summary of Reference Architectures =====
+^ Architecture ^ Domain ^ Key Features ^ Communication Model ^
+| ROS / ROS 2 | General / Research | Modular, open-source, community-driven | Publish–Subscribe (DDS) |
+| AUTOSAR Adaptive | Automotive | Safety, real-time, standardised | Service-oriented (SOME/IP, DDS) |
+| JAUS | Defence / Multi-domain | Interoperability, hierarchy-based | Message-based |
+| MOOS-IvP | Marine | Behaviour-based, decentralised | Shared database model |
+Recent trends combine multiple reference architectures to exploit their strengths. For example:
+  * **ROS–AUTOSAR** bridges enable integration between experimental and production-grade systems.
+  * **DDS–MQTT** hybrids connect real-time robotics with cloud-based IoT analytics.
+  * **ROS–MOOS** integrations allow cross-domain cooperation between underwater and surface robots ((Petillot, Y., et al. (2020). Underwater robotics: Hybrid autonomy and AI integration. Annual Reviews in Control, 50, 238–254)).
+Such hybridization reflects the growing need for flexibility and cross-domain interoperability in modern autonomous systems.

en/safeav/as/refarchitectures.1760692267.txt.gz · Last modified: 2025/10/17 09:11 by agrisnik