Open Standard for the communication between electronic SCUBA equipment

1. Open Standard for the communication between electronic SCUBA equipment Benefits & Requirements overview Sven Paepke

2. Table of Content • Purpose of the standard • Current status • A possible future state • Benefits • Scenarios • The standard • Conceptual architecture • Requirements/features • Next steps

3. Purpose of the standard • To develop and promote an open, vendor independent standard for the communication between electronic equipment used in SCUBA applications • To assist vendors with the development of standard-compliant electronic equipment for use in SCUBA applications

4. Current status • No interfaces exist, or, vendor proprietary interfaces • If a vendor does not offer a gadget with the required features, the user can only resort to home-build • Small after-market, because of the small market being further fragmented by vendor and product • User cannot mix and match

5. Current Status – cont. • Manufacturers have to develop every device themselves – resulting in significant R&D, tooling, testing, manufacturing cost • Manufacturers have to divert significant capital to the development of add-on gadgets, rather than being able to focus on their core product(s)

6. A possible future state • An Open, cross-industry, standard exists that gives manufacturers of dive computers, electronic gauges, closed circuit rebreather electronics, PC software vendors and home builders access to information within 3rd party devices • Users can combine devices from different vendors in order to set up their dive gear to suit their budget, the purpose of the dive and their level of diving • Vendors can sell into a larger market

7. Benefits • For the manufacturer • Focus capital on further development of the core product • Can still develop add-ons later • Potential to sell to larger market – the market size is only determined by the number of devices that support the standard • More simple designs – eg. the device may not need a display • New gadgets possible – eg. a HUD that warns of deco ceiling violations, besides showing the status of the O2 sensors • Cheaper development as interfaces have been defined already • For the user • Mix and match of devices from different vendors is possible • Can continue to upgrade or replace equipment • Can chose most appropriate, or most suitable combination of devices • Can extend the equipment by adding new devices

8. Scenario #1: Download of Dive Log to a PC by an Open Circuit diver

9. Scenario #2: Connecting an aftermarket HUD to an Electronic Closed Circuit Rebreather

10. Scenario #3: Connecting a dive computer to an Electronic Closed Circuit Rebreather

11. Scenario #4: ????

12. The standard • Release 1: Sending only, no feedback • Release 2: Two way communication between devices, extended set of data • Data standards • Physical standards (wired/wireless) • Procedures: comments, enhancements, release • Certification: testing, cerification • Using the standard

13. Conceptual architecture • Senders: • Dive computer • Electronic depth gauge • eCCR electronics • Electronic compass • Listeners • HUD • Dive computer • Sensor • Data sets • Current depth, time, dive time, temp, … • O2 sensor status and data • … Data set #abc Device B (Listener) Device B (Sender) Device A (Sender) Device C (Listener) Data set #def

14. Requirements/features • No guaranteed delivery • Wired and wireless • Wet-pluggable • Useful set of devices and data

15. Next steps • Enlist support and participation of at least two major vendors • Set up a Standards Committee • Finalise requirements for Release 1 • Develop standard and achieve sign-off by the parties involved • Evangelise  • Prepare Release 2