Modular Hardware Architecture for the Development of Underwater Vehicles Based on Systems Engineering

Abstract

This paper addresses the development of a modular hardware architecture for the design/construction/operation of a remotely operated vehicle (ROV), based on systems engineering. The Vee model is first presented as a sequential process that emphasizes the validation processes with stakeholders and verification plans in the development and production stages of the ROV’s life cycle. The conceptual design process starts with the mapping of user requirements to engineering specifications, using the House of Quality (HoQ), a quality function deployment tool that allows executing a functional-division-based hardware design process that facilitates the integration of components and subsystems, as desired for modular architectures. Then, the functional division and hardware architectures are described, and their connection is made through the proposed system architecture that sets the foundation for the definition of a physical architecture, as it involves flows that connect abstract functions with a real context. Development and production stages are exemplified through the design, construction, and integration of some hardware components needed for the remotely operated vehicle Pionero500, and the operational stage briefly describes the first sea trials conducted for the ROV. Systems engineering has shown to be a very useful tool for the development of marine vehicles and marine engineering projects that require modular architectures.

1. Introduction

The comprehensive study and sustainable use of the oceans has been accelerated together with the development of underwater vehicles and underwater intervention technologies that have enable the accessing of remote sites [1]. Hence, it can be seen that ocean exploration is relying nowadays mostly on robotic and several advanced technologies [2,3,4]. Although several developments have been focused on remotely operated (ROV), autonomous (AUV) and surface (USV) vehicles [3,5,6,7], it has been identified that other marine systems also require the combination of mechanics, electronics, software, and control, to be developed and appropriately integrated [8,9,10,11,12,13]. As it can be seen in literature, the development of underwater vehicles (AUVs and ROVs) has been accelerated in the second part of the last decade, considering different operation scenarios and operation conditions.

Regarding AUVs, Ribas et al. [14] reported the integration of mechatronic components for the AUV developed in the EU FP7 TRIDENT project. Spears et al. [15] developed the Icefin, an unmanned underwater vehicle (UUV) for deployment in permanently ice-covered oceans. meng Jiang et al. [16] reported the motion control system design for a pipeline detection AUV. Li et al. [17] described the structural design of a novel water-jet-based spherical underwater robot. Gelli et al. [18] described the electromechanical design of a small/light-weight AUV for archaeological applications. Pugi et al. [19] presented a reconfigurable propulsion system for a harsh-environment inspection vehicle. Hong et al. [20] developed an autonomous visual inspection system for ship hull inspection. Costa et al. [21] developed an ostraciiform swimming AUV. Ignacio et al. [22] reported the development of a torpedo-body AUV, for deep-exploration of the Caribbean Sea. Xu et al. [23] presented the design of an AUV for hydrological surveying of plateau rivers and lakes. Cozijn et al. [24] reported the design and construction of a modular AUV to be used for research projects at the Maritime Research Institute Netherlands (MARIN).

Regarding the development of ROVs in the last five years, Pinjare et al. [25] presented the description of a low-cost ROV prototype based on Raspberry Pi and Arduino UNO. Capocci et al. [26] reported a new thruster fault-tolerant control system to be used in open-frame ROVs. Rozman et al. [27] described the characteristics of the small ROV GNOME pro, that will be used for assessing the radiation background of water areas. Zhang et al. [28] described the development of a 6000-meter depth rating ROV for ocean research at Shenyang Institute of Automation, China. Kadiyam and Mohan [29] proposed the design of a hybrid-propulsion underwater robotic vehicle (HPURV) for minimum energy consumption in ocean exploration. Kong et al. [30] outlined the development of an autonomous/remote underwater vehicle, named Intelligence Ocean I(IO-I), that can operate in ROV or AUV modes.

Because the complexity and scale of many engineering systems have increased during the last decades, systems integration has been identified to be key in order to enable the interactions of components that provide the functionality needed by the system [31,32]. As defined by NASA [33], “Systems Engineering (SE) is defined as a methodical, multi-disciplinary approach for the design, realization, technical management, operations, and retirement of a system”. Such integrative discipline has allowed developing and operating systems while meeting requirements that in several cases are subject to opposite constraints [33]. SE has been used to develop different types of unmanned robotic systems, considering functional requirements [34]. For instance, Eaton et al. [35] provided a high-level modular system architecture for the development of unmanned aerial systems (UAS) considering different platforms types and mission requirements. More recently, Hien et al. [36] developed a hybrid control model for quadrotor unmanned aerial vehicles based on Model-Based Systems Engineering (MBSE) approach combined with the real-time Unified Modeling Language (UML)/Systems Modeling Language (SysML). Regarding the maritime domain, Weinert et al. [37] discussed the need for using architectural methodologies to overcome the challenge to coordinate the development of new systems considering technological issues, governance aspects and users. Recently, Freire et al. [38] developed a functional AUV based on SE concepts such as functional classification, design patterns, interface and compatibility assessment, and integration policies, among others.

At the beginning of the 2010s decade, hardware systems engineering had been using mostly classical development techniques, opposite to software development that had started using agile system engineering practices [39]. However, nowadays it is possible to find recent reports regarding the development of hardware architectures for robotic systems [40,41,42,43] and marine vehicles [44,45,46,47,48,49,50] that have evolved considerably ever since. Nonetheless, several recent developments of marine vehicles reported in the literature [16,17,18,20,21,23,24,25,30,51,52] do not consider a functional-division-based design process that facilitates the integration of components and subsystems, which is desired for modular hardware architectures.

This work represents an extension of [53] and addresses the use of systems engineering as a very useful tool for the development of marine vehicles and marine engineering projects that require modular hardware architectures. This is exemplified through the design, construction and integration of the hardware components for the remotely operated vehicle Pionero500, developed to operate up to 500 m, based on the vehicle’s functional division. This ROV was developed in order to reduce the gap in the development of marine technologies in Colombia. The organization of the paper is as follows. Section 2 describes the methodology used in the system’s hardware development process. Section 3 addresses the SE-based conceptual design. Then, Section 4 and Section 5 present development and production stages of the hardware architecture. Section 6 contains some details about the first sea trials for the ROV Pionero500. Finally, conclusions are provided in Section 7.

2. Methodology

An ROV is a complex system. Hence, every stage of its life cycle must be planned carefully, from the beginning in the concept stage, through development, production, operation, support stages, to the end with the retirement stage; such stages can be addressed thoroughly with the SE methodology. Engineering design methods and tools, described in detail in [54], are compatible with SE, being useful in problem definition, solution selection, problem solving, concept and detail design. A simple and common way to present the life cycle for a product is over a horizontal timeline. However, this representation hides the iterative and recursive nature of development and production stages [55]. An improved method that allows addressing this issue is the Vee Model.

2.1. Vee Model

The Vee Model [56] combines main features of cascade and spiral models, often used in software development environments [57]. The Vee is sequential and emphasizes validation processes with stakeholders, as well as definition of verification plans in the development and production stages of the product’s life cycle. Figure 1 presents the Vee Model used for the ROV Pionero500 project, especially during hardware development, and will be discussed and referred to within this document.

In this model, project maturity and development increases from left to right (in time). The vertical components of the Vee enable the development team to rapidly shift perspectives between upper levels, involving requirements and functions, and lower ones that are related to detailed design and implementation [55].

2.2. Baselines

Baselines are vertical lines that mark key moments in the project’s timeline. Each baseline separates approved and verified activities to the left, from those to be considered, approved and verified on the right. The Vee’s multiple vertical levels are crossed by the baselines drawn with a bidirectional arrow, referring to possible iterations among levels: on the top arrowhead, iterations involving stakeholders; on the bottom one, low level iterations and prototyping. Further in this document, the baselines displayed and numbered in Figure 1 will be presented at the beginning of each section, as they guide the activities described for each stage. Stakeholder involvement (top arrowhead) and low level (bottom arrowhead) iterations are also considered.

2.3. Integration, Verification and Validation (IV&V)

IV&V activities are represented horizontally on the Vee, being perpendicular to the baselines. Such activities provide a plan that specify how to integrate, verify and validate the results of the nuclear stages of the Vee. Selection of strategies for IV&V is done according to the main activity of the baseline. These activities are mainly relevant during development and production stages, on each of the vertical levels, as they are key to a successful implementation of the conceived and designed solutions. Especial efforts on prototyping activities are done at system, subsystem and component level, in order to prevent reworks and errors in the production of components, integration of subsystems, and system-level operation.

3. Conceptual Design

As shown in Figure 1, baseline 1, the functional architecture definition is the expected product of this stage. A particular effort was made by the hardware development team, alongside the client, to identify which system functions were relevant regarding hardware and software. Such identification required using tools described in engineering design and SE literature [54,58], such as Product Design Specification and Quality Function Deployment (QFD). The implementation of these elements was made by the main design team, and is described in [59]. Concept generation tools were used to provide possible solutions, such as low-resolution prototypes, breadboard circuits, cardboard models, among others. A cooperative/iterative effort between the client, which in this context played also the role of user, and the development team, led to a list of requirements. Additionally, an extensive engineering characteristics list was built. The former represents qualitative aspects of the desired solution; the latter is associated with quantities that serve as quality indicators. Requirements help the design team to identify which engineering characteristics are to be prioritized. A tool commonly associated with a QFD, known as the House of Quality (HoQ), was used to rank such characteristics by quantifying the influence of the requirements on them. An HoQ was built for the whole ROV system, but it is beyond the scope of this paper. A reduced view, focused on displaying hardware-related elements is shown in Figure 2. One of the main benefits of the HoQ is that the customer’s needs and Engineering Specifications (ES) are established. This exercise led to the ranking of requirements and engineering characteristics for the hardware systems. The most influential requirements are power reliability, illumination, security, and maneuverability. The following list contains the ES for the HoQ:

• Power system autonomy time.
• Average current (and range) of electrical power transmission
• Number of additional ports for connecting auxiliary equipment
• Energy storage capacity in the vehicle
• Power consumed by the propulsion system
• Supply voltage
• Maximum consumption current allowed
• Number of devices required for the power supply system
• Nominal power transmission voltage
• Control system response time
• Surface station size
• Average power demanded by the system
• Longitudinal advance thrust
• Additional ports available on the surface for connecting devices
• Power consumed by the lighting system
• Power consumed by the launch/recovery system
• Cable length
• Up/down thrust
• Umbilical cable gauge
• Existence of an electrical protection system
• Number of people needed to operate the system
• Number of lights
• Total illumination intensity
• Total number of thrusters
• Power (capacity/required availability) supply
• Vehicle dimensions
• Vehicle weight in air

3.1. Functional Architecture

The functional architecture is a viable solution to the design problem that satisfies the established requirements. It is abstract by definition, and it aims at accomplishing the system’s mission and guaranteeing its operation throughout the life cycle [55]. The ROV functional architecture describes, in a concrete and graphical manner, which functions are to be performed by the system. A general version of the whole system’s functional architecture is shown in Figure 3. Only the top level functions are displayed, as the details are out of the scope of this document.

3.2. Hardware Architecture Definition

From the electrical and software systems perspective, a classification exercise was done to filter which functions had to be performed using hardware and software. Such effort rendered that all the top level functions are related to hardware and software, and can be divided into specific subfunctions. The next step was to connect each subfunction using energy, matter, and information flows, according to a product engineering perspective [58]. The resulting diagram is called Systems Architecture, which is shown in Figure 4 for the ROV Pionero500. This tool represents an important step towards physical implementation of abstract functions, since it allows transitioning from functional decomposition to physical architecture. Once flows are established, boundaries between systems can be drawn. In this case, three systems were declared for the underwater vehicle: Energy, Processing, and Physical Samples.

The Energy System implements energy management functions for the entire ROV. It has two input flows that serve as energy source: matter with energetic potential such as fuel; and unregulated electric power sources, usually, but not limited to, ship’s power supply. At least one of the flows has to be processed to generate usable energy for the ROV. An energy backup function is included to address recovery on failures. Energy transmission has to be guaranteed inside the entire architecture, as shown with the energy flow that runs from top to bottom. Energy measurements are done by monitoring functions present in all the systems. High-level decisions and system-level commands regarding energy functions are performed by the Processing System. Nevertheless, protection functions, which are present in all the systems, can override such commands in emergency situations to prevent or mitigate energy-related failures. Energy for ROV motion is physically managed by the Energy System, under the Processing System’s commands. Similarly, Physical Samples System manages energy for its own processes, also depending on Processing Systems information flow. Communication functions are implemented through the entire ROV system with corresponding functions. General protection functions are also included in all the systems and provided autonomy to act upon potential/effective critical failures. A general protection function is deployed in the Processing System for addressing non-critical failures and high-level decision making processes.

External input flows can be classified in three groups: surface, environment variables and samples. The first is composed mainly by interactions with operators, databases, and other sources of information, as well as surface variables of interest, such as Global Positioning System signals, Internet access, among others. The second includes variables measured underwater. Finally, the third one includes sediment and liquid samples that are to be taken by the ROV. The first two groups interact directly with the Processing System. The third is processed by the Physical Samples System.

The Systems Architecture sets the foundation for the definition of a physical architecture, as it involves flows that connect abstract functions with a real context. Although the methodology considers the functional architecture as the baseline of this stage, the Systems Architecture serves as an intermediate step that facilitates the transition to the next stage, which involves the physical realization of the solution.

4. Development Stage

The baseline established for this stage is the detailed definition of a physical architecture for hardware and software systems (see Figure 1). Declared activities for prognostic and problem solving are mainly related to concept evaluation and alternative selection. Compatibility between the resulting architecture and user requirements must be guaranteed. For this reason, the selection process for every solution needs to consider such requirements, i.e., stakeholders must be part of these processes to ensure compatibility.

In this stage, hardware and software architecture functions (see Figure 4) were subject of analysis by the entire development team, in order to generate concept solutions. Then, a selection process was carried out with specific areas of the design team using weighted comparison matrices. Other selection specific methods such as the Pugh’s chart [54,58] can also be used. After the selection of concepts, the relationship between them was established. The refinement of this exercise leaded to the Hardware Architecture.

4.1. Hardware Architecture

The resulting Hardware Architecture is shown in Figure 5. Generally, the components of the ROV can be segmented in three groups: subsea systems, which include the vehicle and all of its components; topside systems, which comprises the components above water level; and the umbilical, which is the main link between subsea and topside systems for the ROV.

4.1.1. Subsea Systems

According to the HoQ (Figure 2), solutions must facilitate connection of additional equipment in the exploration system. In response to this, subsea systems are modular, allowing developers to add functionality through modules with new components (e.g., additional sensors).

The boundaries established in the Hardware and Software Systems Architecture were translated to physical systems in the ROV. Each system is contained in a watertight enclosure, and named according to its main function. Those enclosures are called Boxes. These boxes can be seen as functional modules. Interfaces for each box are established, physically through a single connector providing data and power. Although the vehicle is modular, three boxes are required for basic functionality: Power Box, CPU Box, and Multiplexer Box (MUX - MacArtney NEXUS MK VI). An additional Junction Box is used to allow the vehicle and the umbilical to be disconnected, as well as to separate fiber-optic cables from power lines.

• The Power Box implements the Energy System’s functions (Figure 4), serving as a power hub that receives three-phase voltage signals from the Junction Box; then, it regulates, distributes and monitors power signals to other boxes and its own components. The Multiplexer Box is the only one that requires alternating current (AC) signals for operation. Other boxes operate on 24 VDC, such as the CPU Box and the Sampler Box. The Power Box manages low-level control and power signal generation for thrusters and lights. Regarding thrust power requirements, the acquired thrusters for Pionero500 operate on 260 VDC. To obtain this voltage level, three-phase AC voltage is rectified using a full-wave rectifier. Then, a motor integration module distributes it to each thruster. The thrusters are vulnerable to ground loop currents that can damage their internal electronics, so an OEM isolation module (ISO-6) was included to guarantee safe electrical operation conditions. Finally, a power management module was developed for low-voltage power signal monitoring and distribution to the rest of the vehicle.
• Multiplexer Box is an Original Equipment Manufacturer (OEM) device, commercially available from MacArtney. It is in charge of communication through a single fiber-optic cable, transmitting three high-definition video signals, a gigabit Ethernet data link for ROV control and box status signals and sensors.
• CPU Box is the main processing module of the vehicle. It contains a processor with a real-time operating system (RTOS) that communicates with the topside systems using a gigabit Ethernet data link. The software developed for vehicle operation follows the same modularity principle, leveraging the RTOS capabilities to implement every processing requirement of the existing modules, while allowing further functionality to be implemented seamlessly. In this box, instruments integration occurs. Minimal required instruments for the ROV operation include: Attitude and Heading and Reference System (AHRS), Conductivity-Temperature-Depth (CTD), altimeter, and Ultra Short Baseline (USBL).
• The Sampler Box is in charge of operating sediment and liquid samplers for Pionero500. Other boxes can be implemented to add functions to the vehicle, as long as the design complies with power and data interfaces restrictions.

The correct implementation of some functions that are present in every system must be guaranteed, specifically related to protect, control, measure, and monitor energy. Smart Cards were developed to locally receive, process, and transmit information between devices, other Smart Cards and the main controller in the CPU Box. Connection to the main controller and other Smart Cards is done through an RS422 bus. Protection solutions involve measurement and monitoring of variables: humidity, temperature, pressure, water leak, electrical current, and voltage. Modularity is a key feature of this design, allowing it to adapt to multiple form factors, including reduced space enclosures, as well as multiple available ports for additional sensor integration.

4.1.2. Umbilical

The umbilical links the vehicle and the surface station that contains topside systems. Technical specifications of the umbilical can be found in [53].

4.1.3. Topside Systems

This group of systems includes solutions to energy and processing functions. Every component of the topside systems are located on a twenty-foot container. Power for the complete ROV system is provided using an external source, usually from the vessel, or internal from a diesel power plant. Power conditioning systems include switchboard for changing between external and internal sources; circuit breaker board to protect the system from short circuit failures; a topside transformer designed to adequate voltage to the level required by the thrusters, considering umbilical conductor’s impedance; control board to implement power supply management, additional electrical protection systems, and the controller of the launch and recovery system (LARS). The LARS consists of a motor with speed reduction, a fiber-optic rotating junction, and a slip ring to connect both fiber and copper lines to the rotating umbilical reel.

The surface station serves as an interface between the operators and the ROV System. It comprises a control room (with air conditioned) that contains a networking rack with the topside controller components, the topside multiplexer (MUX - MacArtney NEXUS MK VI), and the user interface with sufficient controls and indicators to control the vehicle and sample taking. The room occupies half container, and has been designed for two operators. The topside controller is a modular hardware and software system mainly based on a main computer, a networking router plus access point for wireless connection, video recording equipment, and an uninterrupted power supply (UPS). This controller supports additional rack mountable modules. The topside multiplexer receives video feed and ROV data through a single fiber-optic link; data are distributed through the router to the main computer. We use a PostgreSQL database as storage for data exchanged between topside and subsea systems. Full HD video from three subsea cameras is converted, recorded and displayed on a dedicated screen on the user interface. External interactions of the surface station include a Global Positioning System (GPS), Internet access through a networking bridge, and an acoustic data link through the USBL. A potential mobile interface can be connected similarly to previous implementations [60], but has not been developed to the date.

Operators interact with the ROV system through a custom-made user interface. It was designed to display simultaneously video feed from the cameras, and the graphical user interface (GUI) developed to control the ROV. This is done through six full HD displays, customizable through the GUI. The interface is designed to be used by two operators: one ROV pilot, in charge of navigation of the vehicle; one co-pilot, designated to operate the sampling system and to support the pilot for navigation tasks. Both operators interact with the system by using a customized control panel. This consists of peripherals such as a trackball, keyboard, joystics, buttons and light indicators. Each operator has a set of peripherals according to the role.

4.1.4. IV&V Activities

As part of the established methodology, IV&V activities allowed the development team to explore, prototype, integrate, and verify concepts previous to design and implementation. In the context of Power Box development, these activities and their connection with development and production stages are illustrated in Figure 6a–c.

For hardware development, concept exploration at unit level can be done by manufacturing circuit boards using rapid prototyping techniques, such as Computer Numerical Control (CNC) milling. For the Power Box, several units had to be designed and integrated. Figure 6a shows the resulting prototyped board to explore an individual thruster protection, activation, and signal generation. With this prototype, the hardware development team could select the required components for the detailed design, as well as identify potential failures circuit-wise. Similar exercises were done with other functions of the Power Box. Such endeavor led to the subsystem integration of Power Box prototype, shown in Figure 6b. This prototype was relevant for integration of hardware with other subsystems, especially for mechanical assembly concept exploration. Foreseeing the system validation on the production stage, a system integration test of the Power Box prototype was conducted, including prototypes of other components of the ROV, from both topside and subsea systems, as shown in Figure 6c. After successfully testing the whole ROV system at a concept level, development stage could be completed with sufficient certainty. Gradually, detailed designs were implemented, starting with the components (Figure 6d), incorporating them to the Power Box design (Figure 6e), and at the same time, integrating the latter to produce the first complete ROV vehicle design (Figure 6f).

5. Production Stage

The baseline established for this stage requires an operational ROV that can be verified and validated on laboratory conditions (see Figure 1). The client must be part of User Acceptance Tests (UAT) and selected Quality Assurance (QA) tests. Prognostic and problem solving activities included specific hardware and software subsystem unit testing and QA testing. Although the ROV system must be seen as a whole, it would exceed the scope of this document. For this reason, the development process, integration, and implementation will be addressed with the Power Box and one of its components.

As established in the baseline, production stage on the low level of the Vee requires unit tests as a mean of verification at component level. Unit tests were conducted to each thruster model, at signal generation and power management levels, see Figure 6g. Particularly, unit testing provided important feedback on the power supply design, as potential issues regarding ground loops were detected and corrected prior to implementation in further stages. Regarding signal generation for thruster motion, Digital to Analog Converter (DAC) technology explored in the concept stage was verified. Similar tests were conducted to other components. At the same time, subsystem integration was being done collaboratively among mechanics, hardware and software development team. Adequate Computer Aided Design (CAD) tools were used to accomplish such collaboration. Main requirements for CAD tools were seamless electrical and mechanical integration and cloud-based collaborative design management.

An example of subsystem integration is displayed in Figure 6h. At this point, QA tests must be conducted with the entire development team to identify and address system-wide issues. Collaboration tools played a key role for troubleshooting: centralized source of information for design and manufacturing, version control with backups and roll-back capability, and communication platform integrated with the design environments for commenting directly on design assets. For the Power Box, hardware and software issues were detected on QA tests, e.g., noise in the communication bus between boxes was detected when connecting the Sampler Box; this issue was solved by isolating the bus’ power supply in the Smart Cards.

After every essential subsystem was integrated and tested, verification tests were conducted, making evident that the ROV system fulfills user requirements in laboratory conditions, as shown in Figure 6i. Multiple tests were carried out in an indoor water tank, and involved mechanical, hardware, and software integration. For the specific case of the Power Box, power supply to the whole vehicle was achieved, providing energy to subsea systems: CPU Box, MUX, Sampler Box and instruments. Successful implementation of movements of the vehicle for the desired degrees of freedom was achieved: heave, sway, surge, and yaw. Sampling systems were also tested with positive results for both physical and digital samples. Finally, validation at this stage required involvement of the client in the aforementioned tests. Correct UAT execution and corresponding approval from the stakeholders mark the transition to the operational stage.

The development of the ROV Pionero500 as a complex system with the use of SE required breaking some barriers regarding the design methodologies that have been used for the design and development of robotic devices. Nevertheless, such traditional design methods and tools have been used during this project at different stages defined in the Vee Model, which at the end represented more iterations for problem definition, solution selection, problem solving, concept and detail design, rising the cost of the design, expressed in more time and participation of several stakeholders (although it was not quantified). However, developing a functional division during the conceptual design stage reduced the time for the physical solution (detailed design) and implementation of the hardware architecture for the vehicle, and production drawbacks were reduced by prototyping at component, subsystem and system levels. Additionally, as agreed with the final user (from Oil&Gas industry), several COTS (commercial off-the-shelf) industrial-grade elements from the offshore industry were used for the production of the a 500-m-depth robust experimental ROV prototype, including cameras, thrusters, standard underwater connectors, sensors, among others; this allowed increasing the robustness of the solution and reducing construction and production times, and balancing the higher cost of the design process.

6. Operational Stage

The operational stage for Pionero500 only involved the first sea trials carried out in 2018 near Cartagena, Colombia (Figure 7) on board of the research vessel ARC Roncador, which is managed by the General Maritime Directorate of Colombia (DIMAR) through the Caribbean Research Center for Oceanographic and Hydrographic Research (CIOH). This was done thanks to an academia-government-industry alliance to conduct research, development, and innovation in marine sciences and technologies, funded by the Newton Fund and the Royal Academy of Engineering from the UK, that allowed the research team to join a cruise in which different technologies for ocean exploration were being evaluated. This partnership included several types of stakeholders and was very useful to feedback the design of the operational characteristics of the ROV system.

Validation in this stage included performing test to all the ROV system. Because it is out of the scope of this work, just a few data from depth (with respect to the surface) and altitude (with respect to the bottom) are shown in Figure 8 for one of the tests performed in shallow waters within the Rosario and San Bernardo Corals National Natural Park.

In this case, we selected two instruments that provide measurements of variables of the same nature and order of magnitude. The test was performed in shallow waters, during a 30 m dive of the ROV, and both sensors (CTD and altimeter) showed appropriate response and provided the expected data from the hardware system. As indicated in Figure 5, such measurements travel through the CPU Box, the MUX, and the Junction Box for the Subsea part, passing through the Umbilical, the LARS, and the Control Board to the Surface Station, where they are displayed on the pilot interface and stored in the database. Future reports will include the development and use of a navigation system (under development) to integrate data from different sensors into the best possible estimate of several variables, which is required to tag visual and physical samples that are to be collected with the ROV. Regarding physical samples, a sampling system to take sediment and semisolid samples using a cylindrical corer, and four bottles to collect water at locations selected in the mission has been developed. Both samplers were built based on commercial ideas, but novel key components for the corer and the bottles have been developed by the design team, and are under patent processes; therefore, no more details are provided on this matter.

7. Conclusions

This paper addressed the development of a modular hardware architecture for the design, construction and operation of a Class-II remotely operated vehicle, named Pionero500, based on system engineering. This methodology is suited for development of complex systems, such as an underwater vehicles and other marine systems that require hardware/software/mechanical/control components.

Stakeholders’ needs were taken as baseline, structuring the system as a solution to those needs from a high-level point of view, and decomposing it into specific solutions. Based on the latter, realization of each individual function was made, along with integration of the solutions, leading to a hardware architecture that fulfills the user’s requirements.

Integration, verification and validation activities helped reduce production drawbacks by prototyping at component, subsystem and system levels. Production tests involving all of the stakeholders rendered in user requirement fulfillment. Finally, the complete system was tested at sea, validating the proposed architecture and proving to be a useful tool for hardware design in an underwater vehicle.