Our oceans cover over 70% of our planet’s surface, drive our climate system, and carry over 90% of the world’s trade. Yet, ocean data is exceedingly sparse. At Sofar, we believe that more and better ocean data will contribute to a greater understanding of our environment, better decisions, improved business outcomes, and ultimately a more sustainable planet.
During the early days of Sofar, designing and shipping sensor systems to customers was prototype heavy. The speed and resourcefulness of the engineering team allowed various concepts to be pursued and validated in the market with consumer and enterprise customers with this prototype ethos. However, when a company is ready to scale its hardware products, a different product design mindset needs to be adopted.
Today, Sofar creates value for our customers across the entire stack. From the hardware platform, generating in situ, ocean observations from every corner of the globe; to the cloud data platform, providing real-time access to all of our deployed sensors (data APIs); to the insights we’re able to deliver to the maritime industry with applications such as Wayfinder Ship Routing. Our hardware sensor platform supports all of these use cases, but in order to be able to truly scale our hardware, we must focus on getting to market quickly with reliable and affordable sensor systems.
To prepare for the future, we reevaluated how we design, build, test and ship our sensor systems in the ocean. We asked ourselves how the hardware engineering team can be responsive to quickly changing payload requirements -- with a speed similar to our software colleagues.
Over the past eight months, we took account of our existing Spotter and Smart Mooring products deployed for open ocean and coastal applications, respectively. If the data captured by sensor payloads creates maximum value for our customers and our customers are exploring a variety of ocean applications, then payload integration should be extremely responsive; it should be integrated and deployed with minimal and predictable engineering effort.
We identified two criteria to satisfy when building future ocean sensing systems:
The approach that we decided to adopt requires a greater focus on modularity.
Engineering sensor systems in a modular fashion is not new. Multiple systems in the aerospace industry (and other industries) are designed in this way.
A close comparison is in the small spacecraft industry, specifically CubeSats. CubeSats consist of constellations of small, inexpensive, and modular sensors in orbit around Earth that help answer targeted scientific (and commercial) questions in a rapid and affordable manner relative to their much larger satellite counterparts.
Over the course of two decades, the modular CubeSat architecture facilitated an explosion in spacecraft experimentation and innovation by dramatically reducing the barrier to space exploration by constraining various aspects of the system, such as structure, size and weight.
Until 2013, universities and research institutions accounted for the majority of CubeSats launched into space. Since then, commercial and non-academic purposes have accounted for half of CubeSat launches (source). CubeSats are seeing growing commercial use as the value generated by this unique design approach starts to be realized.
At Sofar, we believe that distributed sensing can unlock scientific and commercial value in the oceans very much like it did in space. We want to help achieve this vision by engineering a reliable and affordable architecture; and opening that architecture up for the community to integrate and deploy new payloads.
An ocean sensing system can be nominally divided into five subsystems: structure, power, communication, compute and payloads. Our engineering team sought to make these subsystems more discrete and interchangeable. For example, changing our battery chemistry should not impact our electronics box; changing our satellite communication system should not impact our float structure; or adding a new payload to meet a customer requirement should allow the team to minimize configurations of deployed systems.
Our engineering team revamped our sensor system architecture by treating payload and float development as independent of one another. Internally, we refer to this architecture as xMoonJelly (named after a species found both in the open ocean and coastal regions).
xMoonJelly is not a single feature and it is difficult to visually identify in our products. It is an under-the-hood framework.
The benefits of a modular architecture such as xMoonJelly are multifold:
Speed. In October 2020, we started designing the next generation Spotter with elements of the xMoonJelly architecture. By the end of May 2021, a mere 7 months later, we expect to deploy it in the ocean. In March 2021, we started integrating elements of the xMoonJelly architecture into the next generation Smart Mooring and expect to have the first set of units deployed within 3 months.
Simplicity. There are a number of opportunities for a modular architecture. One is a simple and hierarchical bill of materials (BOM). The system BOM is defined with a top level part number and made up of a handful of subassemblies. Each subassembly is built up of child components. Since each subassembly is discrete and fully documented, contract manufacturers can be onboarded and support builds by subassembly versus waiting for the entire system to be mature and have parts on hand.
Reliability. Our new framework helps the engineering team across mechanical, electrical, software and manufacturing to assess and address localized risk by subassembly. This forces our team to answer the biggest unknowns first. For example after a recent set of drop tests from a 100 foot height, our team realized we needed to improve the structural integrity of our battery subassembly. This design change was completed in a matter of days, cross-referenced with our supply chain team for part availability; formally discussed in a design review; and rolled into design lock by the end of the week. The change improves system reliability, but since it is localized, allows for quick iteration while maintaining revision control at the subsystem and system level.
Affordability. Our engineering team was able to iteratively reduce BOM cost by half over the course of a month prior to deployment. A BOM structured modularly allows the team to drive quick design sprints based on subassembly risk (answer the biggest unknowns first-mindset). It also empowers our team to reduce system level BOM cost by focusing our attention on individual subassemblies. Often with a more integrated, bespoke approach to sensor system product design, changes to a design late in the process can be overwhelming given the multiple dependencies across components.
One trade off of modularity is more interconnects. On this topic, our team was strategic in our bias towards off the shelf interfaces. But when such an interface did not exist or was unsuitable (e.g. cost), we were deliberate in defining a new standard or mapping existing Sofar R&D efforts to hardware’s broader strategy for modularity. One project we are excited about is Bristlemouth (named after the most abundant vertebrate genus in the world). We cannot wait to share more about Bristlemouth and how we are building a community and an open platform for capturing ocean data to be used by everyone.
Paving the way for expanded ocean exploration and data collection requires a new approach. Borrowing from learnings in space exploration, our hardware team is already focused on deploying a modular approach to engineering the next generation of devices.
If you’re interested in joining the team, check out our careers page.
