Development of a Modular Software Architecture for Underwater Vehicles Using Systems Engineering

Abstract

This paper addresses the development of a modular software architecture for the design/construction/operation of a remotely operated vehicle (ROV), based on systems engineering. First, systems engineering and the Vee model are presented with the objective of defining the interactions of the stakeholders with the software architecture development team and establishing the baselines that must be met in each development phase. In the development stage, the definition of the architecture and its connection with the hardware is presented, taking into account the use of the actor model, which represents the high-level software architecture used to solve concurrency problems. Subsequently, the structure of the classes is defined both at high and low levels in the instruments using the object-oriented programming paradigm. Finally, unit tests are developed for each component in the software architecture, quality assessment tests are implemented for system functions fulfillment, and a field sea trial for testing different modules of the vehicle is described. This approach is well suited for the development of complex systems such as marine vehicles and those systems which require scalability and modularity to add functionalities.

1. Introduction

The development of modern technologies that have been used in ocean exploration, including unmanned marine vehicles, has allowed reaching inaccessible regions all around the world, which is helpful for the comprehensive study of the ocean [1]. These robotic vehicles have been mostly divided into three types: remotely operated (ROV) [1,2], autonomous (AUV) [3,4], and surface (USV) [5,6] vehicles, and, as is usual in different robotic devices, all of them need the combination of mechanics, hardware, software, and control strategies to be developed and appropriately integrated. This combination of disciplines has been also proven to be useful for other types of marine systems such as advanced monitoring environments [7], aerial systems [8], electric ships [9], cleaning robots [10], alarm systems [11], multirobot systems [12,13], and research platforms [14], among others. Hence, the development of modern marine systems and vehicles represents an open problem, which depends on the operational conditions and user requirements.

The development of underwater vehicles during the last five years has increased considerably for different applications, depending on the type of missions that are to be executed [15]. For AUVs, one can find reports with vehicles to be used in ice-covered oceans [16], pipeline detection [17], rapid and accurate vehicles [18], archaeological survey [19], harsh environments inspection [20], ship hull inspection [21], deep-sea exploration [3], and hydrological surveying [22], among others. For ROVs, the last five years’ developments include low-cost ROV prototypes [23], fault-tolerant control systems [2], small ROV for assessing radiation [24], deep-ocean research [25], energy-efficient vehicles [26], hybrid vehicles that can work either as ROV or AUV [27], and motion feasibility frameworks based on industry standards [28].

Systems engineering (SE) has been defined by NASA [29] as “a methodical, multi-disciplinary approach for the design, realization, technical management, operations, and retirement of a system” and has been identified to be a key discipline to enable the interactions of components that provide functionality within a complex system [30,31] that is expected to meet several requirements [29]. Some robotic systems developments that have used SE by considering functional requirements [32,33] include, among others, unmanned aerial systems [34], quadrotor aerial vehicles [35], and specific frameworks regarding the maritime domain [36].

The development of software systems, based on the functional decomposition started at the beginning of the 1990s, with object-oriented approaches proposed to replace the traditional software life cycle [37]. In the decade of the 2000s, software development for underwater vehicles was focused on the implementation of real-time platforms to be used with hierarchical control structures [38,39]. Later, in the 2010s, embedded systems were frequently used within the hardware architecture for robotic systems [40,41,42], which required more advanced software architectures in order to allow integrating new components [43] into the vehicles while guaranteeing real-time operation and the execution of several tasks [44] and more challenging missions [45,46]. More recently, because of the sophistication of autonomous systems, new opportunities for maritime activities have appeared in the scenario [47] and more advanced and flexible software systems are being required. Regarding this matter, Bozhinoski et al. [48] performed an extensive review from a software engineering perspective on solutions for mobile robotic systems that will need to be able to operate in uncontrollable and unknown environments. For instance, Yu et al. [49] proposed a two-layer software architecture for a hybrid underwater vehicle that exhibited a satisfactory multi-task processing performance. Nowadays, underwater cooperative robotics offers the possibility to perform challenging survey, operation, and intervention tasks [50,51,52,53] that require developments that allow the users to expand the capabilities of underwater robots.

As a response of adaptability needs for underwater vehicles, this work addresses the development of a flexible and modular software architecture developed with the use of systems engineering, considering a functional division during the design process in order to facilitate the integration of components and subsystems, which is desired for modern hardware and software architectures. Together with the work of [54], the proposed modularity for hardware/software systems represents a contribution in the field of underwater vehicles, which are complex multifunctional systems that require flexibility, depending on the tasks that they are expected to execute. Such flexibility is also important for operational stages that require simulation campaigns, which are employed before the vehicle is deployed in a realistic scenario, as has been reported in [55], who built a continuous validation framework in the scope of the EU project DexROV [56]. This work exemplifies the process for the remotely operated vehicle Pionero500, 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 software development process. Section 3 addresses the SE-based software architecture. Then, Section 4 contains some details about the first sea trials for the ROV Pionero500. Finally, conclusions are provided in Section 5.

2. Methodology

2.1. Systems Engineering Approach

Systems engineering was used to build and process all stages of the ROV life cycle, from its conception to its retirement stage, considering that it is a complex system in which multiple disciplines interact. Due to this complexity, its life cycle cannot be represented through a horizontal timeline, since, naturally, throughout the development of the stages, iterations can occur, hence giving different dynamics that are finally better represented by methods such as the Vee model.

Aristizábal et al. [54] provided a description of how SE has been used to construct the functional division of the ROV system, using product design specification (PDS) and quality function deployment (QFD). Thanks to a cooperative/iterative effort between the client and the development team, extensive lists of requirements and engineering characteristics were built and evaluated through the use of the House of Quality (HoQ), a tool commonly associated with a QFD used to rank characteristics by quantifying the influence of the requirements on them. A comprehensive HoQ was built for the whole ROV system, but it is beyond the scope of this paper. In order to generate a set of engineering specifications (ES), the HoQ exercise was conducted for the hardware and software systems and reported by [54]; this ES list shows the complexity of the system that has to be developed to fulfill stakeholders’ expectations and that requires the modular software architecture that is being reported:

• 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.

Functional Decomposition

After the definition of the ES, the development of the functional decomposition is required to understand the connections between parts of the system which are unknown before executing the detailed design in order to fulfill the established requirements [57]. The resulting system’s architecture can be represented graphically, and describes the desired functions to be performed by the designed solution. Figure 1 presents a simplified functional decomposition for the ROV Pionero500, as reported in [54,58], a complex and complicated system in which multiple functions must be performed, often with internal and external interactions. As addressed in [54], this system’s architecture sets the foundations for the definition of a physical architecture, since it involves flows that connect abstract functions with a real context. Consequently, this is also the basis to define and develop a software architecture that allows the ROV system to perform all the functions it has been designed for, while being modular and flexible.

2.2. Modular Hardware Architecture

Figure 2 shows the hardware architecture and physical components of the ROV that were developed by Aristizábal et al. [54]. Three main groups can be identified: subsea systems (which include the vehicle itself and all its components), topside systems (components that are at the surface station), and the umbilical cable that connects the first two systems and guarantees the flow of data and energy.

In order to achieve modularity, subsea systems were approached by modules in compartments called boxes, which were named according to the main function they perform. Thus, there are three functional boxes, or modules, that are required for basic functionality: power box (functions of the power system), CPU box (main processing module of the vehicle), and mux box (multiplexer responsible for communications). In addition, thanks to the modularity, there is another box called the sampler box that is in charge of operating the sediment and liquid samplers for the ROV Pionero500. In the same way, other boxes can be used to add functions to the vehicle, as long as the design meets the power and data constraints.

2.3. Vee Model

The V model is a basic model of traditional systems engineering. According to NASA [29] and INCOSE [57] systems engineering handbooks, technical processes can be organized and managed according to this model [59]. The V model shows the stages of the life cycle that are executed through levels, but carrying out verification and validations at the end of each stage in order to ensure that failures are not propagated in later stages, to finally verify that the user’s requirements have been fulfilled. In this way, then, the diagram begins in the upper left part with the definition of user requirements and ends in the upper right part with the confirmation of such requirements. The left side explains the requirement-based design process from top to bottom, while the right side explains the validation and integration process from bottom to top [60]. Part of the model used on the ROV Pionero500 is shown in Figure 3, focusing on development and production stages, while concept and operation stages are addressed deeply in [54]. The outcome of such stages is mostly common for both software and hardware systems.

The model defines stakeholders interactions (Figure 3). This is useful for validation on both stages, development and production, and at every implementation level vertically; for instance, think of architectural design that must be validated with stakeholders, as well as its implementation in production stage. One of the main elements of the model are the baselines, that are established during the early stages of the project and must be fulfilled at the end of each stage, indicating the beginning of the next one, as it happens for hardware and software systems. Prognostic and problem-solving actions and tools are specified as detailed as possible with the resources available when developing the model (lower part of the diagram in Figure 3). Regarding software development, engineering design selection processes applied to choose an architecture and then producing a prototype were specified among such activities at the development stage. Production stage tools in this context comprise typical software tests applied to both hardware and software systems, such as unit testing (UT) and quality assurance (QA).

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

The IV&V activities provide a plan that indicates how to integrate, verify, and validate the results of the Vee stages. They are represented horizontally and are key in the development and production stages. Additionally, they are reinforced during prototyping activities in order to avoid reprocesses and errors in integration stages.

The Vee model is widely used in the development of complex products because it uses iterative processes such as design–redesign and think–rethink, which are essential to prevent problems from spreading from one stage to another by using IV&V activities; this allows avoiding transferring errors and incomplete results to subsequent stages which will lead to failure at the end of the project [60]. Regarding software development for Pionero500, IV&V activities involve mainly typical software tests, applied to early models and prototypes of the results expected at the baseline. An appropriate example is an early user acceptance test (UAT) activity executed for software architecture selection: the team designed and implemented a semi-functional mockup software made to test different models during architecture design; it reused both hardware and software elements from previous developments [61] while incorporating a novel distribution. The mockup was presented to the stakeholders, aiming to receive acceptance and validate the selected architecture.

2.5. Actor Model

Concurrency problems are common in systems that execute several tasks at the same time, i.e., parallel, distributed, and mobile systems [62]. The actor model addresses these issues, being a concurrent computing model where the actors are autonomous objects that operate simultaneously and asynchronously [63], communicate by means of messages, and have a clearly established communication infrastructure [64,65]. The actor model introduces some simple rules to control state sharing and cooperation between execution units and directly attack concurrency problems from two fronts: there is no deadlock in the system since each actor is independent and there is always a replacement in case their answer is missing [62,66,67,68]. The independence of the actors favors modularity, because they make it possible to add knowledge as the system grows without having to completely rewrite it and to obtain maximum parallelism by participating in several conversations at the same time [69,70]. Furthermore, they can be used as a framework to model, understand, and gain reason about a wide range of concurrent systems [70]. Modularity, independence of processes, and concurrent work capability within a development team made the actor model appropriate for structuring high-level software systems in Pionero500. A model that requires parallel execution at its core has specific performance requirements and, usually, its implementation is not appropriate in platforms with limited resources, such as microcontrollers. For these devices, simplified modular architecture approaches based on object-oriented programming can be used instead.

2.6. Object-Oriented Programming

Object-oriented programming (OOP) is a programming paradigm that allows gathering data and functionality on a piece of code (object) with unique attributes and behavior. OOP is focused on the objects and its functions rather than the logic required to work with them. OOP is a well-suited programming paradigm for the development of software architectures for robotic systems due to reusability, scalability, and efficiency characteristics of code. For example, Hien et al. [35] presented an object-oriented system to develop controllers on unmanned aerial vehicles. Mouelhi et al. [71] presented a software design approach for cooperative autonomous systems based on Ada standars. Xu and Li [72] developed an object-oriented software architecture for a modular agricultural robotic system; the software was designed using a robot operating system (ROS) using three object-oriented modules: control, navigation, and vision module. For underwater vehicles, OOP is useful for low-level systems that involve microcontrollers up to high-level systems, such as human–machine interfaces. In low-level systems, modularity allows different sensors to be connected using the same software architecture. In high-level software components, scalability allows third-party software to be integrated into the mission.

Reconfigurable Input–Output Architecture

For the ROV Pionero500, the National Instruments™ CompactRIO^® system, which is an industrial embedded controller, was selected because it meets the requirements of the reconfigurable architecture, since it is a processing system with high-performance capabilities, sensor input and output systems, and programming tools directly related to LabVIEW^®. In addition, it responds to real-time processing needs with reliable and predictable behavior. Finally, the field programmable gate array (FPGA) contained in its chassis provides high-speed processing and precise timing.

Given the requirements, it was decided to use LabVIEW given its high performance in parallel processing, where the actors are conceived in independent virtual instruments (VI), launched through the LabVIEW base tools for parallel execution, following the RIO (reconfigurable input output) architecture, given the potential that offers to connect hardware and software modules [73,74]. LabVIEW queues were implemented as a means of communication, so that the actors can communicate asynchronously, sending and receiving messages at any time [68].

3. Modular Software Architecture Definition

Modularity means that the design is based on a set of independent blocks, called modules, whose structure and behavior follow certain rules. The modular design allows developing scalable systems and makes components of the system to be reusable in a collaborative development [75]. For Pionero500, this modularity has been addressed hardware-wise in [54]. To introduce the corresponding software architecture, a customized unified modeling language (UML) deployment diagram is presented in Figure 4 to establish its relationship with physical systems.

Physical modules are represented as UML nodes, and are differentiated in the architecture according to its dependability. Some modules are required for the architecture to work; others can be removed or added, including original equipment manufacturer (OEM) modules that are usually closed software platforms; custom devices are developed from scratch. An example of required modules are those associated with communication tasks and data processing, such as topside computer, Ethernet switch, multiplexer units, and the National Instruments (NI) CompactRIO (cRIO) vehicle’s computer. Modules with software that has been developed or modified by the team are distinguished from the rest by having UML components inside. Finally, this structure considers other components that can be added in the future, which gives advantages in terms of modularity and scalability.

Components that are hosted in NI MyRIO, computer, and NI cRIO have been developed in LabVIEW. Real-time capabilities of the RIO-based devices are leveraged to improve the prioritized engineering specifications, such as control system’s time response. Gigabit Ethernet compatibility was also established as a requirement for communication devices on the main link between topside and subsea devices, such as computer, Ethernet switch, multiplexers, and NI cRIO. The NI cRIO serves as the main processing unit of the vehicle and is equipped with a communication module that allows it to exchange data with every instrument on board: altimeter, AHRS, CTD, and USBL modem, regardless of the physical standard. For example, while the CTD uses RS-232, the AHRS uses RS-422. It also communicates with every box’s SmartCard in a master–slave scheme, using an RS-422 full-duplex bus.

Each SmartCard processing unit is a 32-bit microcontroller. One of the key characteristics taken into account for microcontroller platform selection was developing an environment and language supporting OOP. In this particular implementation, Atmel^® SAM3X series complied with this specification. Arduino^™ provided a simplified framework for implementing functionality while reducing development time by using third-party libraries provided by device manufacturers and developers community.

3.1. Software Components Architecture

A general view of the designed software architecture is displayed by using a modified UML components diagram. Figure 5 represents Pionero500’s software component architecture. The design is layered, with top levels being close to the user, and bottom levels addressing low-level signals and devices. The user level defines interactions with users through interfaces. The topside level involves components hosted mostly on the topside computer, where the actor model is implemented. The instrument level regards the vehicle main computer and instruments components. Both the topside and instrument levels’ coding language is National Instruments LabVIEW. Finally, the device level comprises firmware components, hosted on SmartCard devices. Further details on SmartCards can be found in [54].

Regarding modularity, components identified with dashed lines are named as additional. This indicates where to include future modules and how they would interact with others in the architecture. For example, an additional actor included in the topside level needs to be launched by ROV\_Interface.vi, and communicates through queues with other actors.

Actor Model Implementation

The last example serves as an introduction to the specific implementation of the actor model in this architecture. As mentioned in Section 2.5, actors essentially need to be independent and a communication channel. Considering this, the development team created its own implementation of an actor-based model in LabVIEW, as third-party approaches added unnecessary complexity to the solution. LabVIEW queues served as communication channels, as they offer asynchronous lossless message exchange, in a first-in first-out (FIFO) manner. Each actor must be created with its own queue, which also must be accessible to every other actor and the actor launcher. For actor execution and termination, the main interface application ROV\_Interface.vi serves as launcher, by running each actor VI using LabVIEW asynchronous VI execution. When running, each actor’s specific user interface, also known in LabVIEW jargon as a front panel, can be accessed through the launcher’s front panel. This feature enables modular and concurrent user interface development, as each actor’s interface can be modified simultaneously without modifying the launcher’s front panel.

Essential actors include COM.vi, which handles communication between topside and instrument level; CI.vi, named after Command Interface, which contains indicators and controls needed for human–machine interaction, and also establishes communication with the ROV command peripherals controller, in this case, an NI MyRIO. Non-essential actors implemented can be removed without affecting basic operation of the whole system, although it involves removing useful features such as instrument data acquisition (DAQ.vi) and mission data storage (DB.vi).

Each actor can interact with multiple external third-party applications. One implementation of this feature is the data acquisition actor DAQ.vi, which establishes communication channels with topside instrument’s own applications, e.g., Ultra Short Baseline (USBL) server or Global Positioning System (GPS) serial data. Regardless of the application, DAQ.vi obtains, processes, and distributes data to other actors or external applications. Another case of interaction with third-party software is the database actor DB.vi, which connects to databases, stores vehicle and mission data, executes queries, and displays information as requested by the operator.

It is worth mentioning that this model has made it easier to extend the system’s functionality, as actors are defined with clear communication schemes: internally, using LabVIEW queues’ asynchronous messaging capability; and externally, exchanging data with additional applications, thanks to the extensive and diverse communication tools provided by the integrated development environment (IDE) and third-party applications developers. On the other hand, not every feature of the actor model is required in lower levels of the architecture, e.g., user interfaces are only present at the topside level components. A simplified model was necessary at the instrument level, without losing modularity and concurrent development capabilities. As described in Section 2.6, the OOP paradigm favors high cohesion, low coupling, modularity, and reusability of code; therefore, it was considered for instrument level software design. The resulting architectural design highlights can be expressed through class diagrams in the following section.

3.2. Class Structures

Pionero500, as an exploration system, mainly benefits from modularity by increasing functions regarding data acquisition from its surrounding environment, thus making instrumentation fundamental for the ROV. This premise oriented the development of a class model that uses the concept of instrument as an abstraction, with functionality added by specification, while sharing some common members. Figure 6 shows a simplified version of the main class structure. An abstract class Instrument is at the top, with multiple children classes inheriting from it. As an abstract class, Instrument functionality is overridden, serving as a template for every child, providing them with essential methods that must be present in all instruments. These generic methods are:

• Init: runs instrument initialization routines, usually for establishing communication with the main processor. It should be called at least once per operation of the vehicle.
• Stop: terminates the operation of the instrument as intended, according to its requirements. Frequent routines implemented by this method are serial buffer clearing and controlled power-off.
• Read: handles data exchange between the instrument and processing unit. Its main function is to accumulate and parse incoming data, but also can implement specific routines, such as requests and process responses.
• Compose: consolidates information in an standardized manner by using a type-defined data structure. The structure is the same for every instrument. This is necessary to facilitate data exchange between the instrument and the whole system.

After inheriting Instrument abstract class, each instrument class implements specific functionality to the inherited methods, while preserving the parent’s calling properties, allowing the main application to call overridden methods iteratively. This is a key aspect of a modular model, as the addition of modules only requires code development of its own implementation, with little to no intervention of main code.

3.2.1. Topside Level Classes

Topside level classes are instantiated in the topside computer, implemented in NI LabVIEW, aided by its OOP tools. Derived classes in this level implement functionality to GPS and USBL instruments. An example of the derived methods and specific implementation can be illustrated with the GPS class; Init method establishes connection with a marine GPS through serial port; Stop closes the port and flushes buffers; Read receives data from the instrument and parses NMEA 0183 frames; Compose writes the type-defined data structure that holds the topside data, making the acquired data available to the whole application at every level. Additional instruments can be easily incorporated to the system at this level by inheriting Instrument class, writing the code needed by the instrument, and instantiating the new derived class in the DAQ.vi actor.

3.2.2. Instrument Level Classes

Topside level classes are instantiated in the NI cRIO processor onboard the vehicle, using the same developing environment, tools, and methods from the topside level. The main difference with the latter relies on real-time capability of RIO devices; this specific implementation uses real-time communication channels, called RT-FIFOs. These operate in a similar way to regular LabVIEW queues, with some restrictions on data types, e.g., fixed size arrays and static type variables, but with the benefit of time-controlled data access operations. Strict actor model implementation was compromised, mainly because of these restricted communication channels, yet benefiting in reliability and deterministic message delivery.

Derived classes at instrument level are shown in Figure 6. Altimeter, AHRS, and CTD are associated with physical OEM instruments integrated to the vehicle. SCard refers to an abstract class that implements similar features of Instrument, as described in Section 3.2. This is made to extend modularity to custom hardware and devices in the form of additional SmartCards. At the time of writing this document, three SmartCards were deployed in the vehicle, each one supporting functional watertight enclosures called Boxes; see [54] for details on hardware aspects. Children of Instrument class can also be associated with non-physical entities or instruments. TOPDATA is a derived class that represents topside data to the vehicle computer as an instrument, standardizing the access method to variables originated at the surface level, such as vessel position and heading, joysticks, and user interface controls.

3.2.3. Device Level Class Structure for Firmware

Firmware development followed the same principles of modularity and concurrent development as the higher levels. Previous successful experiences from the hardware development team in modular, OOP-based architectures running on microcontrollers [61] supported this approach, and established the starting point for the device level class structure design. Figure 7 presents a simplified class diagram that implements an adapted version of the modular class models developed for upper levels of the architecture. Here, an abstract class Device serves a similar purpose to Instrument class of Figure 6, as functionality is implemented by deriving devices. In this case, calling of devices is in charge of the class Device Manager, which instantiates every device and handles execution of its inherited methods. Such methods are device_setup, similar to Instruments Init, this is meant to be executed once at startup and contains routines to initialize devices, and device_loop, which contains device routines that have to execute periodically.

In this design, external communication with the main vehicle processor is handled by Command class, which is instantiated once in global scope, and used by Device Manager to enable interaction of devices with the rest of the ROV. As an internal communication channel between devices, Command uses the Internal Command class, which is a simplified and lighter version of the former.

Regarding specific devices, the ones displayed in Figure 7 actually represent a collection of devices. SC_Devices is a derived class which implements functionality of internal SmartCard devices such as temperature, humidity and pressure sensor, status indicator, voltage, and current sensor. POWER, CPU, and SAMPLER group distinguishdevices according to each box, e.g., thruster signal generation is performed in a device class that is only implemented in POWER Box. Detailed firmware class structure exceeds the scope of this document.

4. Testing

Tests covered in this section regard production and operation stages. The type of test used is closely related to the location in the timeline of the project, both horizontally to the life cycle stage, and vertically to the Vee specification component. Unit tests are useful during implementation of low-level components and specific functions of the system. QA is composed mainly of integration tests in controlled conditions. UAT is carried out in both laboratory and field tests.

4.1. Unit Testing

Unit testing is a practice in software development which helps to maintain code and bug detection. It allows correcting any errors before the deployment of the system in an uncontrolled environment. Since the developed architecture was based on actor model, each element is tested by launching it independently, sending messages, and waiting for the correct answer. For example, for the database actor, some messages with dummy data (similar to data provided by sensors) were produced, and it was verified that they were stored. Most of the test coverage was performed from a functional criteria taking into account the functional architecture given in the previous sections. Another successful example is the thruster driving system, that benefited from early unit tests, as control signal generation was prototyped by integrating OEM demonstration modules for digital-to-analog converters (DAC), Arduino^™ libraries, and a simple software interface developed in LabVIEW. The latter was also used to test fundamental programming tools, such as LabVIEW queues and latency in serial communication between the microcontroller and software interface. Both generated signals and LabVIEW interface are shown in Figure 8.

4.2. Quality Assurance

These tests verified the integration of elements to the designed architecture, aiming to fulfill at least one of the functions referred in the product design specifications (PDS) [54]. This is better explained by expanding a previous database example: one of the main functions presented in the PDS is to collect information; to fulfill this, real variables must be measured by instruments, collected by the NI cRIO, transmitted to the topside computer and, finally, stored in the database by the corresponding actor. It is worth mentioning that such tests can be performed in laboratory conditions, as long as the instruments can operate, e.g., CTD, USBL, and Altimeter have to be underwater to work properly. As QA tests require element integration to allow the pilot to interact with the vehicle, a user interface must be provided. Figure 9 shows a screenshot of the front panel used by the ROV pilot, and is currently displaying the navigation tab. A tabbed design was selected regarding front-end layout, as it is compatible with the modular approach, allowing the development team to add functionality through different tabs. Most of the tabs content is essentially each actor’s individual front panel, integrated to the same interface through LabVIEW subpanel function, which enables real concurrent development among the team.

4.3. User Acceptance Testing

The first sea trials for Pionero500 were carried out in Cartagena, Colombia as described in [54], with the cooperation of the General Maritime Directorate of Colombia (DIMAR) and its Caribbean Research Center for Oceanographic and Hydrographic Research (CIOH), using the research vessel ARC Roncador. These field tests were performed within an academia–government industry that included several stakeholders, and were very useful to perform not only the UAT but to gain feedback of operational characteristics of the ROV system, which is undergoing a software update nowadays, together with the development of a navigation system. The main objective of the partnership is to develop a generalized framework that integrates modern tools and methods that are useful for the characterization of underwater ecosystems in order to strengthen decision-making processes in Colombia.

The field exercise was conducted at two national parks: Corales de Profundidad National Natural Park, which is located next to an oil and gas exploration block, and Parque Nacional Natural Corales del Rosario y San Bernardo. Figure 10 shows ROV Pionero500’s system on the R/V ARC Roncador, which is managed by the General Maritime Directorate of Colombia (DIMAR) and its Caribbean Research Center for Oceanographic and Hydrographic Research (CIOH); this image shows the vehicle and a twenty-foot container that carries the tether management device and a backup power supply. The field exercise was directed in such a way that the use of modern methods for the characterization of underwater ecosystems were applied, bringing a particular focus to supporting collaborations among several stakeholders of data users and producers to implement collective action solutions to improve the availability and quality of data for development of different offshore activities in the country.

Figure 11 shows different elements of the ROV’s operational stage during a ground truthing session, where the vehicle is used to visually verify selected places from the initial sea bottom model built with the use of bathymetry information of the surveyed area. As an example of the software modularity, the actor DAQ.vi and the USBL class USBL (see Section 3.2.1) were modified during the test in order to connect the ROV system data to OpenCPN, a third-party application that is used to create a chart plotter that displays live ROV position and heading over mission-specific map provided in the vessel.

Validation in this stage included performing tests on all the ROV system, with integrated hardware and software architectures. Figure 12 shows the interface that allows the user to interact with the control module. This module gives the possibility to change parameters for manual control (thrust allocation), depth control, altitude control, heading control, and thrust control. Control algorithms have been implemented in the NI cRIO, taking advantage of the real-time system; details of the control systems are beyond of the scope of this work.

5. Conclusions

This paper addressed the development of a modular/flexible software architecture for a Class-II remotely operated vehicle, named Pionero500, based on system engineering. This methodology is suited for the development of complex systems (including underwater vehicles and maritime systems), which starts with the understanding of user requirements from a functional level to provide a solution.

The actor model was implemented as a solution to reduce time and complexity in the development of the vehicle as a high-level software architecture. Such an architecture is useful to solve concurrency problems since the actors can operate simultaneously and independently. Object-oriented programming was used in instrument-level software design as a solution to decrease coupling in code, and increase cohesion, modularity, and reusability, which are highly desired characteristics in a complex underwater exploration system.

Finally, IV&V activities helped reducing time for software design at each level. These activities were applied to early models in order to generate a baseline, and in the end they were compared with the final integrated solution. The complete system was tested at sea, and allowed the development team to add required functions during the trials, validating the proposed architecture and proving to be a useful tool for software design for underwater vehicles and maritime systems.